Subject: Order Shipped -- Order #50146

From: [email-masked], [email-masked], [email-masked], "Dose <provreg-archive"@ietf.org
Date: Wed, 29 Apr 2009 17:25:59 -0700 (PDT)

Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Department, 33 East Minor Street, Emmaus, PA 18098

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 n3NCOUa4019075 for ; Thu, 23 Apr 2009 14:24:30 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n3NCOUeH026165 for ietf-provreg-outgoing; Thu, 23 Apr 2009 14:24:30 +0200 (MEST)
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 n3NCOTv2002356 for ; Thu, 23 Apr 2009 14:24:29 +0200 (MEST)
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 n3NCF0GZ015146; Thu, 23 Apr 2009 08:15:00 -0400
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, 23 Apr 2009 08:24:27 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs
Date: Thu, 23 Apr 2009 08:24:28 -0400
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Standards Track Advancement Request for EPP RFCs
Thread-Index: Acm9yfhyB5hfNV7HSw2hjJK2mRfanAGREiFg
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
From: "Hollenbeck, Scott"
To: "Alexey Melnikov"
Cc:
X-OriginalArrivalTime: 23 Apr 2009 12:24:27.0798 (UTC) FILETIME=[72005360:01C9C40E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n3NCOTv2028369
Sender: [email-masked]
Precedence: bulk

4934bis-01 just submitted:

http://www.ietf.org/internet-drafts/draft-hollenbeck-rfc4934bis-01.txt

-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 n3MHOrY3008064 for ; Wed, 22 Apr 2009 19:24:53 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n3MHOrZF016837 for ietf-provreg-outgoing; Wed, 22 Apr 2009 19:24:53 +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 n3MHOq9i005173 for ; Wed, 22 Apr 2009 19:24:53 +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 n3MHGMrT011430 for ; Wed, 22 Apr 2009 13:16:22 -0400
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, 22 Apr 2009 18:24:51 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [ietf-provreg] RE: Text Proposal for the TLS Usage Profile
Date: Wed, 22 Apr 2009 13:24:54 -0400
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Text Proposal for the TLS Usage Profile
Thread-Index: AcnBtlJ3wuYfcq9nTMqUS2v8Sbs8KwBuMXWA
References: <[email-masked]>
From: "Hollenbeck, Scott"
To:
X-OriginalArrivalTime: 22 Apr 2009 17:24:51.0541 (UTC) FILETIME=[3E938050:01C9C36F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n3MHOr9i027621
Sender: [email-masked]
Precedence: bulk

OK, if there are no issues with the text I'll roll this into a new
version of the document.

-Scott-

> -----Original Message-----
> From: Hollenbeck, Scott
> Sent: Monday, April 20, 2009 8:49 AM
> To: [email-masked]
> Subject: Text Proposal for the TLS Usage Profile
>
> Alexey sent me text to include in the 4934bis TLS Usage
> Profile. How does this look to everyone?
>
> -Scott-
> ----------
>
> If the client has external information as to the expected
> identity of the server, the hostname check MAY be omitted.
> (For instance, a client may be connecting to a machine whose
> address and hostname are dynamic but the client knows the
> certificate that the server will
> present.) In such cases, it is important to narrow the scope
> of acceptable certificates as much as possible in order to
> prevent man in the middle attacks. In special cases, it may
> be appropriate for the client to simply ignore the server's
> identity, but it must be understood that this leaves the
> connection open to active attack.
>
> During the TLS negotiation, the EPP client MUST check its
> understanding of the server hostname/IP address against the
> server's identity as presented in the server Certificate
> message, in order to prevent man-in-the-middle attacks. In
> this section, the client's understanding of the server's
> identity is called the "reference identity".
>
> Checking is performed according to the following rules and in
> the specified order:
>
> o If the reference identity is a hostname:
>
> 1. If a subjectAltName extension of the dNSName [X509]
> type is present
> in the server's certificate, then it SHOULD be used as the
> source of the server's identity. Matching is performed as
> described in Section 7.2 of [RFC5280], with the exception that
> wildcard matching (see below) is allowed for dNSName
> type. If the
> certificate contains multiple names (e.g., more than one
> dNSName field), then a match with any one of the fields is
> considered acceptable.
>
> The '*' (ASCII 42) wildcard character is allowed in
> subjectAltName
> values of type dNSName, and then only as the left-most (least
> significant) DNS label in that value. This wildcard
> matches any
> left-most DNS label in the server name. That is, the subject
> *.example.com matches the server names a.example.com and
> b.example.com, but does not match example.com or
> a.b.example.com.
>
> 2. The server's identity MAY also be verified by comparing the
> reference identity to the Common Name (CN) [RFC4519] value in
> the leaf Relative Distinguished Name (RDN) of the subjectName
> field of the server's certificate. This comparison is
> performed using the rules for comparison of DNS names in
> bullet 1 above (including wildcard matching).
> Although the use of the Common Name
> value is existing practice, it is deprecated, and
> Certification Authorities are encouraged to provide
> subjectAltName values instead. Note that the TLS
> implementation may represent DNs in certificates according to
> X.500 or other conventions. For example, some X.500
> implementations order the RDNs in a DN using a left-to-right
> (most significant to least significant) convention instead of
> LDAP's right- to-left convention.
>
> o When the reference identity is an IP address, the iPAddress
> subjectAltName SHOULD be used by the client for comparison.
> In such case the reference identity MUST be
> converted to the "network byte order" octet string representation
> [RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the
> octet string will contain exactly four octets. For IP
> Version 6, as
> specified in RFC 2460, the octet string will contain
> exactly sixteen
> octets. This octet string is then compared against subjectAltName
> values of type iPAddress. A match occurs if the reference identity
> octet string and value octet strings are identical.
>
> If the server identity check fails, user-oriented clients
> SHOULD either notify the user (clients MAY give the user the
> opportunity to continue with the EPP session in this case) or
> close the transport connection and indicate that the server's
> identity is suspect. Automated clients SHOULD return or log
> an error indicating that the server's identity is suspect
> and/or SHOULD close the transport connection. Automated
> clients MAY provide a configuration setting that disables
> this check, but MUST provide a setting which enables it.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 n3KCmdju003640 for ; Mon, 20 Apr 2009 14:48:39 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n3KCmdAJ009108 for ietf-provreg-outgoing; Mon, 20 Apr 2009 14:48:39 +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 n3KCmcxk024689 for ; Mon, 20 Apr 2009 14:48:38 +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 n3KCeCYg002566 for ; Mon, 20 Apr 2009 08:40:12 -0400
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, 20 Apr 2009 13:48:37 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [ietf-provreg] Text Proposal for the TLS Usage Profile
Date: Mon, 20 Apr 2009 08:48:36 -0400
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Text Proposal for the TLS Usage Profile
Thread-Index: AcnBtlJ3wuYfcq9nTMqUS2v8Sbs8Kw==
From: "Hollenbeck, Scott"
To:
X-OriginalArrivalTime: 20 Apr 2009 12:48:37.0655 (UTC) FILETIME=[52F1B270:01C9C1B6]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n3KCmdxk005845
Sender: [email-masked]
Precedence: bulk

Alexey sent me text to include in the 4934bis TLS Usage Profile. How
does this look to everyone?

-Scott-
----------

If the client has external information as to the expected identity of
the server, the hostname check MAY be omitted. (For instance, a
client may be connecting to a machine whose address and hostname are
dynamic but the client knows the certificate that the server will
present.) In such cases, it is important to narrow the scope of
acceptable certificates as much as possible in order to prevent man
in the middle attacks. In special cases, it may be appropriate for
the client to simply ignore the server's identity, but it must be
understood that this leaves the connection open to active attack.

During the TLS negotiation, the EPP client MUST check its
understanding of the server hostname/IP address against the server's
identity as presented in the server Certificate message, in order to
prevent man-in-the-middle attacks. In this section, the client's
understanding of the server's identity is called the "reference
identity".

Checking is performed according to the following rules and in the
specified order:

o If the reference identity is a hostname:

1. If a subjectAltName extension of the dNSName [X509] type is
present
in the server's certificate, then it SHOULD be used as the
source of the server's identity. Matching is performed as
described in Section 7.2 of [RFC5280], with the exception that
wildcard matching (see below) is allowed for dNSName type. If
the
certificate contains multiple names (e.g., more than one
dNSName field), then a match with any one of the fields is
considered acceptable.

The '*' (ASCII 42) wildcard character is allowed in
subjectAltName
values of type dNSName, and then only as the left-most (least
significant) DNS label in that value. This wildcard matches any
left-most DNS label in the server name. That is, the subject
*.example.com matches the server names a.example.com and
b.example.com, but does not match example.com or a.b.example.com.

2. The server's identity MAY also be verified by comparing the
reference identity to the Common Name (CN) [RFC4519] value in
the leaf Relative Distinguished Name (RDN) of the subjectName
field of the server's certificate. This comparison is
performed using the rules for comparison of DNS names in
bullet 1 above (including wildcard matching). Although the use
of the Common Name
value is existing practice, it is deprecated, and
Certification Authorities are encouraged to provide
subjectAltName values instead. Note that the TLS
implementation may represent DNs in certificates according to
X.500 or other conventions. For example, some X.500
implementations order the RDNs in a DN using a left-to-right
(most significant to least significant) convention instead of
LDAP's right- to-left convention.

o When the reference identity is an IP address, the iPAddress
subjectAltName SHOULD be used by the client for comparison.
In such case the reference identity MUST be
converted to the "network byte order" octet string representation
[RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the
octet string will contain exactly four octets. For IP Version 6, as
specified in RFC 2460, the octet string will contain exactly sixteen
octets. This octet string is then compared against subjectAltName
values of type iPAddress. A match occurs if the reference identity
octet string and value octet strings are identical.

If the server identity check fails, user-oriented clients SHOULD
either notify the user (clients MAY give the user the opportunity to
continue with the EPP session in this case) or close the
transport connection and indicate that the server's identity is
suspect. Automated clients SHOULD return or log an error indicating
that the server's identity is suspect and/or SHOULD close the
transport connection. Automated clients MAY provide a configuration
setting that disables this check, but MUST provide a setting which
enables it.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 n3FLjEZD008614 for ; Wed, 15 Apr 2009 23:45:14 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n3FLjEO4003145 for ietf-provreg-outgoing; Wed, 15 Apr 2009 23:45:14 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [213.154.224.50]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n3FLjE0Z028501 for ; Wed, 15 Apr 2009 23:45:14 +0200 (MEST)
Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n3FLjAkQ034555 for ; Wed, 15 Apr 2009 23:45:10 +0200 (CEST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
To: [email-masked]
Subject: [ietf-provreg] Administrative note
Date: Wed, 15 Apr 2009 23:45:09 +0200
From: Jaap Akkerhuis
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (bartok.nlnetlabs.nl [127.0.0.1]); Wed, 15 Apr 2009 23:45:10 +0200 (CEST)
X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, MISSING_MID autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bartok.nlnetlabs.nl
Sender: [email-masked]
Precedence: bulk

This mailing list is still hosted at cafax.se and also archived there at
http://www.cafax.se/ietf-provreg/maillist/.

There are currently 232 subscribers to this list. To put this in
perspective, this is roughly the same amount as in the time that
working group was active.

There is still a status page http://tools.ietf.org/wg/provreg/
maintained by the ietf tools team.

jaap (aka ietf-provreg list administrator)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 n3FJckIC023353 for ; Wed, 15 Apr 2009 21:38:46 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n3FJckKJ028511 for ietf-provreg-outgoing; Wed, 15 Apr 2009 21:38:46 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [213.154.224.50]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n3FJcjjG028435 for ; Wed, 15 Apr 2009 21:38:45 +0200 (MEST)
Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n3FJcg8F095212; Wed, 15 Apr 2009 21:38:42 +0200 (CEST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
To: Edward Lewis
cc: [email-masked]
Subject: Re: [ietf-provreg] who's running the list?
In-reply-to: Your message of Wed, 15 Apr 2009 14:50:41 -0400.
Date: Wed, 15 Apr 2009 21:38:42 +0200
From: Jaap Akkerhuis
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (bartok.nlnetlabs.nl [127.0.0.1]); Wed, 15 Apr 2009 21:38:42 +0200 (CEST)
X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, MISSING_MID autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bartok.nlnetlabs.nl
Sender: [email-masked]
Precedence: bulk

Sorry for this...but is anyone administering this list? ;)

I have a request to make off-list.

I still do that, yes. I forgo about your earlier request because of
personal circumstances.

jaap

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n3FJQrKK000760 for ; Wed, 15 Apr 2009 21:26:53 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n3FJQrbi001868 for ietf-provreg-outgoing; Wed, 15 Apr 2009 21:26:53 +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 n3FJQqu1020607 for ; Wed, 15 Apr 2009 21:26:53 +0200 (MEST)
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 n3FJIZQG025058; Wed, 15 Apr 2009 15:18:35 -0400
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, 15 Apr 2009 15:26:51 -0400
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] who's running the list?
Date: Wed, 15 Apr 2009 15:26:42 -0400
Message-ID: <[email-masked]>
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-provreg] who's running the list?
Thread-Index: Acm9/8JDRQ+Yy9TvQ5GSqWPxPenPCAAAERrA
References:
From: "Hollenbeck, Scott"
To: "Edward Lewis" ,
X-OriginalArrivalTime: 15 Apr 2009 19:26:51.0993 (UTC) FILETIME=[21039490:01C9BE00]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n3FJQru1005428
Sender: [email-masked]
Precedence: bulk

I believe the guy you're looking for is Lars-Johan Liman:

http://www.cafax.se/~liman/

-Scott-

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Edward Lewis
> Sent: Wednesday, April 15, 2009 2:51 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [ietf-provreg] who's running the list?
>
> Sorry for this...but is anyone administering this list? ;)
>
> I have a request to make off-list.
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> -=-=-=-=-=-=-
> Edward Lewis
> NeuStar You can leave a voice message at
> +1-571-434-5468
>
> Getting everything you want is easy if you don't want much.
>

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 n3FIoonq002371 for ; Wed, 15 Apr 2009 20:50:50 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n3FIoosL029642 for ietf-provreg-outgoing; Wed, 15 Apr 2009 20:50:50 +0200 (MEST)
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 n3FIonYN018733 for ; Wed, 15 Apr 2009 20:50:49 +0200 (MEST)
Received: from [10.31.200.240] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n3FIohZr052283; Wed, 15 Apr 2009 14:50:43 -0400 (EDT) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
Date: Wed, 15 Apr 2009 14:50:41 -0400
To: [email-masked]
From: Edward Lewis
Subject: [ietf-provreg] who's running the list?
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20
Sender: [email-masked]
Precedence: bulk

Sorry for this...but is anyone administering this list? ;)

I have a request to make off-list.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468

Getting everything you want is easy if you don't want much.

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 n3FFZfOl004957 for ; Wed, 15 Apr 2009 17:35:41 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n3FFZfXP028546 for ietf-provreg-outgoing; Wed, 15 Apr 2009 17:35:41 +0200 (MEST)
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 n3FFZeHI023880 for ; Wed, 15 Apr 2009 17:35:41 +0200 (MEST)
Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id n3FFQRXk032631; Wed, 15 Apr 2009 11:26:27 -0400
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Apr 2009 11:35:39 -0400
Received: from 10.131.29.236 ([10.131.29.236]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Wed, 15 Apr 2009 15:35:39 +0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Wed, 15 Apr 2009 11:35:34 -0400
Subject: Re: [ietf-provreg] FW: Standards Track Advancement Request for EPP RFCs
From: James Gould
To: "Hollenbeck, Scott" , EPP Provreg
CC: Alexey Melnikov
Message-ID:
Thread-Topic: [ietf-provreg] FW: Standards Track Advancement Request for EPP RFCs
Thread-Index: Acm9yUplMVhAPeYsR02cHb4dQNUdwgAAEopAAAWPIlE=
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3322640136_29144593"
X-OriginalArrivalTime: 15 Apr 2009 15:35:39.0841 (UTC) FILETIME=[D4912B10:01C9BDDF]
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_3322640136_29144593
Content-type: text/plain;
charset="US-ASCII"
Content-transfer-encoding: 7bit

The server certificate used for the .com and .net Registry is below.

-----BEGIN CERTIFICATE-----
MIIDvjCCAyugAwIBAgIQAdOiHXYdPJ44modnaXlVHTANBgkqhkiG9w0BAQUFADBf
MQswCQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4x
LjAsBgNVBAsTJVNlY3VyZSBTZXJ2ZXIgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw
HhcNMDgwNjA1MDAwMDAwWhcNMDkwNjE1MjM1OTU5WjB3MQswCQYDVQQGEwJVUzER
MA8GA1UECBMIVmlyZ2luaWExDzANBgNVBAcUBkR1bGxlczEXMBUGA1UEChQOVmVy
aVNpZ24sIEluYy4xDDAKBgNVBAsUA08vSTEdMBsGA1UEAxQUZXBwLnZlcmlzaWdu
LWdycy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOYneJtSM1Z2lwCN
ryBAg11e3HB8mg0VonJ9DRbZ3ptINmZ4YDOKLz/ht7A/Cpl62RIp3fGIKKo5DKwy
zJsOpom2SYlHjE91EurqnGn/+IKUZ05M3N5b7+dXWlZ4phlA12ihJJAsAeKdpcVT
7fuaxRsnt/KWXumGTxu9965c4YyJAgMBAAGjggFlMIIBYTAJBgNVHRMEAjAAMAsG
A1UdDwQEAwIFoDA8BgNVHR8ENTAzMDGgL6AthitodHRwOi8vY3JsLnZlcmlzaWdu
LmNvbS9SU0FTZWN1cmVTZXJ2ZXIuY3JsMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH
FwMwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTAd
BgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwNAYIKwYBBQUHAQEEKDAmMCQG
CCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wbgYIKwYBBQUHAQwE
YjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ
UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEu
Z2lmMA0GCSqGSIb3DQEBBQUAA34Ah5ipMrh5dJS7rUF9uQSMX2C/fz/8wxwF9nuI
+l3nxMy8HpuXpigJEmP70GNXyP9G2S9P1J4cNWKD0wX2nJmBy3oepQ47HLDyN685
kmqbc4WFj0Z7kVzKDGau+zueb+3juAJ10y8FTS1Fn8NnVDJiKNouMDq26n/bsENC
bOc=
-----END CERTIFICATE-----

--

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: "Hollenbeck, Scott"
Date: Wed, 15 Apr 2009 09:00:22 -0400
To: EPP Provreg
Cc: Alexey Melnikov
Subject: [ietf-provreg] FW: Standards Track Advancement Request for EPP RFCs

Can any implementers share copies of the certificates used for the EPP
implementation report testing [1] or, if they're not available, samples
of what you're using now? Read below for rationale (Alexey is the new
AD I'm working with for our document progression request).

-Scott-

[1]
http://www.ietf.org/IESG/Implementations/RFCs3730-3734_implem.txt

-----Original Message-----
From: Alexey Melnikov [mailto:[email-masked]]
Sent: Wednesday, April 15, 2009 8:54 AM
To: Hollenbeck, Scott
Cc: Chris Newman
Subject: Re: Standards Track Advancement Request for EPP RFCs

Hollenbeck, Scott wrote:

>Given that the testing took place a few years ago, and I didn't do it,
>it's highly unlikely. I *might* be able to get implementers to share
>whatever they're currently using, but I'll have to ask.
>
>
This would help too. Thanks.

>-Scott-
>
>
>>-----Original Message-----
>>From: Alexey Melnikov [mailto:[email-masked]]
>>Sent: Wednesday, April 15, 2009 8:45 AM
>>To: Hollenbeck, Scott
>>Cc: Chris Newman
>>Subject: Re: Standards Track Advancement Request for EPP RFCs
>>
>>Scott,
>>The EPP implementation report says that both client and server TLS
>>authentication was verified for all test implementations.
>>Can you extract and send me certificates used for these tests (I need
>>at least 2 server certificates. Ideally all of them)?
>>
>>

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

The server certificate used for the .com and .net Registry is below.

-----BEGIN CERTIFICATE-----

MIIDvjCCAyugAwIBAgIQAdOiHXYdPJ44modnaXlVHTANBgkqhkiG9w0BAQUFADBf

MQswCQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4x

LjAsBgNVBAsTJVNlY3VyZSBTZXJ2ZXIgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw

HhcNMDgwNjA1MDAwMDAwWhcNMDkwNjE1MjM1OTU5WjB3MQswCQYDVQQGEwJVUzER

MA8GA1UECBMIVmlyZ2luaWExDzANBgNVBAcUBkR1bGxlczEXMBUGA1UEChQOVmVy

aVNpZ24sIEluYy4xDDAKBgNVBAsUA08vSTEdMBsGA1UEAxQUZXBwLnZlcmlzaWdu

LWdycy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOYneJtSM1Z2lwCN

ryBAg11e3HB8mg0VonJ9DRbZ3ptINmZ4YDOKLz/ht7A/Cpl62RIp3fGIKKo5DKwy

zJsOpom2SYlHjE91EurqnGn/+IKUZ05M3N5b7+dXWlZ4phlA12ihJJAsAeKdpcVT

7fuaxRsnt/KWXumGTxu9965c4YyJAgMBAAGjggFlMIIBYTAJBgNVHRMEAjAAMAsG

A1UdDwQEAwIFoDA8BgNVHR8ENTAzMDGgL6AthitodHRwOi8vY3JsLnZlcmlzaWdu

LmNvbS9SU0FTZWN1cmVTZXJ2ZXIuY3JsMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH

FwMwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTAd

BgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwNAYIKwYBBQUHAQEEKDAmMCQG

CCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wbgYIKwYBBQUHAQwE

YjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ

UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEu

Z2lmMA0GCSqGSIb3DQEBBQUAA34Ah5ipMrh5dJS7rUF9uQSMX2C/fz/8wxwF9nuI

+l3nxMy8HpuXpigJEmP70GNXyP9G2S9P1J4cNWKD0wX2nJmBy3oepQ47HLDyN685

kmqbc4WFj0Z7kVzKDGau+zueb+3juAJ10y8FTS1Fn8NnVDJiKNouMDq26n/bsENC

bOc=3D

-----END CERTIFICATE-----

=

--

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: "Hollenbeck, Scott&=
quot; <[email-masked]>=
;

Date: Wed, 15 Apr 2009 09:00:22 -0400

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

Cc: Alexey Melnikov <alexey.m=
[email-masked]>

Subject: [ietf-provreg] FW: Standards Track Advancement Request for =
EPP RFCs

Can any implementers share copies of the certificates used for the EPP

implementation report testing [1] or, if they're not available, samples

of what you're using now?  Read below for rationale (Alexey is the new=

AD I'm working with for our document progression request).

-Scott-

[1]

http://www.ietf.org/IESG/Implementations/RFCs3730-3734_implem.txt

-----Original Message-----

From: Alexey Melnikov [mailto:al=
[email-masked]]

Sent: Wednesday, April 15, 2009 8:54 AM

To: Hollenbeck, Scott

Cc: Chris Newman

Subject: Re: Standards Track Advancement Request for EPP RFCs

Hollenbeck, Scott wrote:

>Given that the testing took place a few years ago, and I didn't do it,<=
BR>
>it's highly unlikely.  I *might* be able to get implementers to sh=
are

>whatever they're currently using, but I'll have to ask.

This would help too. Thanks.

>-Scott-

>>-----Original Message-----

>>From: Alexey Melnikov [m=
ailto:[email-masked]]

>>Sent: Wednesday, April 15, 2009 8:45 AM

>>To: Hollenbeck, Scott

>>Cc: Chris Newman

>>Subject: Re: Standards Track Advancement Request for EPP RFCs

>>Scott,

>>The EPP implementation report says that both client and server TLS<=
BR>
>>authentication was verified for all test implementations.

>>Can you extract and send me certificates used for these tests (I ne=
ed

>>at least 2 server certificates. Ideally all of them)?

--B_3322640136_29144593--

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 n3FD0Q8V024742 for ; Wed, 15 Apr 2009 15:00:26 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n3FD0Q0f028019 for ietf-provreg-outgoing; Wed, 15 Apr 2009 15:00:26 +0200 (MEST)
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 n3FD0PfU007531 for ; Wed, 15 Apr 2009 15:00:26 +0200 (MEST)
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 n3FCpBC2023437; Wed, 15 Apr 2009 08:51:11 -0400
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, 15 Apr 2009 14:00:22 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [ietf-provreg] FW: Standards Track Advancement Request for EPP RFCs
Date: Wed, 15 Apr 2009 09:00:22 -0400
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Standards Track Advancement Request for EPP RFCs
Thread-Index: Acm9yUplMVhAPeYsR02cHb4dQNUdwgAAEopA
From: "Hollenbeck, Scott"
To:
Cc: "Alexey Melnikov"
X-OriginalArrivalTime: 15 Apr 2009 13:00:22.0485 (UTC) FILETIME=[22FD7850:01C9BDCA]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n3FD0QfU002797
Sender: [email-masked]
Precedence: bulk

Can any implementers share copies of the certificates used for the EPP
implementation report testing [1] or, if they're not available, samples
of what you're using now? Read below for rationale (Alexey is the new
AD I'm working with for our document progression request).

-Scott-

[1]
http://www.ietf.org/IESG/Implementations/RFCs3730-3734_implem.txt

-----Original Message-----
From: Alexey Melnikov [mailto:[email-masked]]
Sent: Wednesday, April 15, 2009 8:54 AM
To: Hollenbeck, Scott
Cc: Chris Newman
Subject: Re: Standards Track Advancement Request for EPP RFCs

Hollenbeck, Scott wrote:

>Given that the testing took place a few years ago, and I didn't do it,
>it's highly unlikely. I *might* be able to get implementers to share
>whatever they're currently using, but I'll have to ask.
>
>
This would help too. Thanks.

>-Scott-
>
>
>>-----Original Message-----
>>From: Alexey Melnikov [mailto:[email-masked]]
>>Sent: Wednesday, April 15, 2009 8:45 AM
>>To: Hollenbeck, Scott
>>Cc: Chris Newman
>>Subject: Re: Standards Track Advancement Request for EPP RFCs
>>
>>Scott,
>>The EPP implementation report says that both client and server TLS
>>authentication was verified for all test implementations.
>>Can you extract and send me certificates used for these tests (I need
>>at least 2 server certificates. Ideally all of them)?
>>
>>

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 n3EDRQlo002442 for ; Tue, 14 Apr 2009 15:27:26 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n3EDRPAK020298 for ietf-provreg-outgoing; Tue, 14 Apr 2009 15:27:25 +0200 (MEST)
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 n3EDROEd016832 for ; Tue, 14 Apr 2009 15:27:25 +0200 (MEST)
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 n3EDIEjF021623 for ; Tue, 14 Apr 2009 09:18:14 -0400
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, 14 Apr 2009 14:27:23 +0100
Received: from 10.131.29.236 ([10.131.29.236]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Tue, 14 Apr 2009 13:27:23 +0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Tue, 14 Apr 2009 09:27:20 -0400
Subject: Re: [ietf-provreg] AD Review Comments: draft-hollenbeck-rfc4934bis-00
From: James Gould
To: "Hollenbeck, Scott" , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] AD Review Comments: draft-hollenbeck-rfc4934bis-00
Thread-Index: Acm8NJmzYO33/ZvpQjq+pbJCVGlx1QATEQdWABw02xAABMLdUg==
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3322546041_26885414"
X-OriginalArrivalTime: 14 Apr 2009 13:27:23.0755 (UTC) FILETIME=[BEEDE3B0:01C9BD04]
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_3322546041_26885414
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Scott,

I agree since the SSL details are typically handled by the toolkit,
language, or SSL provider with no explicit control by the EPP developer.

--=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: "Hollenbeck, Scott"
Date: Tue, 14 Apr 2009 07:14:58 -0400
To: James Gould , EPP Provreg
Subject: RE: [ietf-provreg] AD Review Comments:
draft-hollenbeck-rfc4934bis-00

According to this reference:
=20
http://download.java.net/jdk7/docs/technotes/guides/security/jsse/JSSERefGu=
i
de.html
=20
it should, but I can't confirm that it does. I'm reasonably certain that
this is behavior that's typically buried in a toolkit instead of being
implemented by an EPP developer, so perhaps that new text should be removed
from the document.
-Scott-=20

=20

> =20
> =20
>=20
> From: Gould, James
> Sent: Monday, April 13, 2009 5:43 PM
> To: Hollenbeck, Scott; EPP Provreg
> Subject: Re: [ietf-provreg] AD Review Comments:
> draft-hollenbeck-rfc4934bis-00
>=20
> =20
> Scott,
>=20
> We=B9re implementing SSL using JSSE in our Java EPP SDK, but I=B9m not sure =
if
> JSSE sends a TLS_close_notify alert before the connection is closed.
>=20
> -- =20
>=20
>=20
> JG=20
>=20
> -------------------------------------------------------
> James F. Gould
> Principal Software Engineer
> VeriSign Naming Services
> [email-masked]
> Direct: 703.948.3271
> Mobile: 703.628.7063
>=20
> =20
> 21345 Ridgetop Circle
> LS2-2-1
> Dulles, VA 20166
>=20
> Notice to Recipient: This e-mail contains confidential, proprietary and/=
or
> Registry Sensitive information intended solely for the recipient and, t=
hus
> may not be retransmitted, reproduced or disclosed without the prior wri=
tten
> consent of VeriSign Naming and Directory Services. If you have receive=
d
> this e-mail message in error, please notify the sender immediately by
> telephone or reply e-mail and destroy the original message without makin=
g a
> copy. Thank you.
>=20
>=20
> =20
>=20
> From: "Hollenbeck, Scott"
> Date: Mon, 13 Apr 2009 08:37:25 -0400
> To: EPP Provreg
> Subject: [ietf-provreg] AD Review Comments: draft-hollenbeck-rfc4934bis=
-00
>=20
> Some feedback from Alexey on the new TLS Usage Profile text in 4934bis.
> I now need implementer feedback.
>=20
>>> >> A client MUST close the associated TLS connection if the connectio=
n
>>> >> is not expected to deliver any EPP messages later. It MUST send a
>>> >> TLS close_notify alert before closing the connection.
>>> >>
>> > As an implementor I remain skeptical that existing implementations do
>> > that. At least I doubt many IMAP or SMTP servers do that. So maybe yo=
u
>=20
>> > should check how existing EPP implementations handle connection
> closure.
>=20
> What are you implementers doing?
>=20
>> > I think the text about how to extract and verify domain information
> from
>> > X.509 certificates is still missing from your draft. I think that wha=
t
>=20
>> > Chris wanted you to do and I am in agreement with him on this.
>> > I see some text on this in Section 8, but I think it is a bit too
> short.
>> > Check section 2.2.1 of draft-ietf-sieve-managesieve-09.txt. It
> probably
>> > contains 80% of what EPP should use.
>=20
> Comments, please. I've sent a note to Alexey pushing back on this
> because (in my opinion) this puts mandates on client and server
> certificate validation behavior that don't affect EPP interoperability.
> If I'm wrong, I'd prefer to cite an existing mature reference instead of
> cloning text from an unapproved I-D. Does anybody know of one?
>=20
> -Scott-
>=20
>=20

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

Re: [ietf-provreg] AD Review Comments: draft-hollenbeck-rfc4934bis-0=
0

Scott,

I agree since the SSL details are typically handled by the toolkit, languag=
e, or SSL provider with no explicit control by the EPP developer.

--

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: "Hollenbeck, Scott&=
quot; <[email-masked]>=
;

Date: Tue, 14 Apr 2009 07:14:58 -0400

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

Subject: RE: [ietf-provreg] AD Review Comments: draft-hollenbeck-rfc=
4934bis-00

According to this reference:

htt=
p://download.java.net/jdk7/docs/technotes/guides/security/jsse/JSSERefGuide.=
html

it should, but I can'=
t confirm that it does.  I'm reasonably certain that this is behavior t=
hat's typically buried in a toolkit instead of being implemented by an EPP d=
eveloper, so perhaps that new text should be removed from the document.

-Scott-

From: Gould, James

Sent: Monday,  April 13, 2009 5:43 PM

To: Hollenbeck, Scott; EPP  Provreg

Subject: Re: [ietf-provreg] AD Review Comments:  draft-hollenbe=
ck-rfc4934bis-00

Scott,

We’re implementing SSL using JSSE in our  Java EPP SDK, but I=
217;m not sure if JSSE sends a TLS_close_notify alert before  the conne=
ction is closed.

--

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 th=
e recipient and,  thus may not be  retransmitted, reproduced or di=
sclosed without the prior  written consent of  VeriSign Naming and=
Directory Services.  If  you have received  this e-mail m=
essage in error, please notify the sender  immediately by  telepho=
ne or reply e-mail and destroy the original  message without making a &=
nbsp;copy.  Thank  you.

From: "Hollenbeck, Scott=
" <[email-masked]&g=
t;

Date:  Mon, 13 Apr 2009 08:37:25 -0400

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

Subject:  [ietf-provreg] AD Review Comments:  draft-hollen=
beck-rfc4934bis-00

Some feedback from Alexey on the new TLS  Usage Profile text in 4934bi=
s.

I now need implementer  feedback.

>>  A client MUST close the associated TLS  connection if t=
he connection

>>  is not expected to deliver any  EPP messages later. &nb=
sp;It MUST send a

>>  TLS close_notify  alert before closing the connection.<=
BR>

> As an implementor I  remain skeptical that existing implementatio=
ns do

> that. At least I  doubt many IMAP or SMTP servers do that. So may=
be you

> should check  how existing EPP implementations handle connection<=
BR>
closure.

What are  you implementers doing?

> I think the text about how to extract and  verify domain informat=
ion

from

> X.509 certificates is still missing  from your draft. I think tha=
t what

> Chris wanted you to do and I am  in agreement with him on this.
> I see some text on this in Section 8,  but I think it is a bit to=
o

short.

> Check section 2.2.1 of  draft-ietf-sieve-managesieve-09.txt. It
probably

> contains 80% of  what EPP should use.

Comments, please.  I've sent a note to Alexey  pushing back on th=
is

because (in my opinion) this puts mandates on client  and server

certificate validation behavior that don't affect EPP  interoperabilit=
y.

If I'm wrong, I'd prefer to cite an existing mature  reference instead=
of

cloning text from an unapproved I-D.  Does  anybody know of one?<=
BR>

-Scott-

=

--B_3322546041_26885414--

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 n3EDNVeS020492 for ; Tue, 14 Apr 2009 15:23:31 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n3EDNVlh011240 for ietf-provreg-outgoing; Tue, 14 Apr 2009 15:23:31 +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 n3EDNViX007609 for ; Tue, 14 Apr 2009 15:23:31 +0200 (MEST)
Received: from triglav.dotandco.com (localhost.localdomain [127.0.0.1]) by mail.dotandco.com (8.13.8/8.13.8/Debian-3) with ESMTP id n3EDNVx7014011; Tue, 14 Apr 2009 15:23:31 +0200
Received: from localhost (localhost [[UNIX: localhost]]) by triglav.dotandco.com (8.13.8/8.13.8/Submit) id n3EDNUFh014010; Tue, 14 Apr 2009 15:23:30 +0200
X-Authentication-Warning: triglav.dotandco.com: patrick set sender to [email-masked] using -f
Date: Tue, 14 Apr 2009 15:23:30 +0200
From: Patrick Mevzek
To: [email-masked]
Subject: Re: [ietf-provreg] AD Review Comments: draft-hollenbeck-rfc4934bis-00
Message-ID: <[email-masked]>
References: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
Organization: Dot And Co
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (mail.dotandco.com [127.0.0.1]); Tue, 14 Apr 2009 15:23:31 +0200 (CEST)
Sender: [email-masked]
Precedence: bulk

Hollenbeck, Scott 2009-04-13 15:00
> > I think the text about how to extract and verify domain information
> from
> > X.509 certificates is still missing from your draft. I think that what
>
> > Chris wanted you to do and I am in agreement with him on this.
> > I see some text on this in Section 8, but I think it is a bit too
> short.
> > Check section 2.2.1 of draft-ietf-sieve-managesieve-09.txt. It
> probably
> > contains 80% of what EPP should use.
>
> Comments, please. I've sent a note to Alexey pushing back on this
> because (in my opinion) this puts mandates on client and server
> certificate validation behavior that don't affect EPP interoperability.

I may be totally blunt, but as I said before there is nothing in the
EPP use of TLS that is specific of EPP, it is just basic
client/server communication.
Some registries are not using TLS at all, specifically on test
servers.
Some registries do use TLS without mandating a specific client
certificate/certification path (that is autogenerated certificates are
accepted).
And I doubt that all clients check the server certificate credentials
(which are not necessarily changed often).
So the specifications should not put too much things on these points.

I may be silly but in my mind few MUST in RFC4934 related to
TLS authentication could be only SHOULD (in section 8), and the whole
part trimmed to say something along the line of 'standard TLS
shortcomings/best practices apply'

In all cases, I agree with the fact that this whole discussion has
nothing to do with EPP interoperability. In that sense, TLS is really
the last worry.

--
Patrick Mevzek
Dot and Co

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 n3EDB6t1026511 for ; Tue, 14 Apr 2009 15:11:06 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n3EDB6ub014438 for ietf-provreg-outgoing; Tue, 14 Apr 2009 15:11:06 +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 n3EDB6kp010998 for ; Tue, 14 Apr 2009 15:11:06 +0200 (MEST)
Received: from triglav.dotandco.com (localhost.localdomain [127.0.0.1]) by mail.dotandco.com (8.13.8/8.13.8/Debian-3) with ESMTP id n3EDB586011235; Tue, 14 Apr 2009 15:11:05 +0200
Received: from localhost (localhost [[UNIX: localhost]]) by triglav.dotandco.com (8.13.8/8.13.8/Submit) id n3EDB5HC011234; Tue, 14 Apr 2009 15:11:05 +0200
X-Authentication-Warning: triglav.dotandco.com: patrick set sender to [email-masked] using -f
Date: Tue, 14 Apr 2009 15:11:05 +0200
From: Patrick Mevzek
To: EPP Provreg
Subject: Re: [ietf-provreg] AD Review Comments: draft-hollenbeck-rfc4934bis-00
Message-ID: <[email-masked]>
References: <[email-masked]> <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
Organization: Dot And Co
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (mail.dotandco.com [127.0.0.1]); Tue, 14 Apr 2009 15:11:06 +0200 (CEST)
Sender: [email-masked]
Precedence: bulk

[about TLS & close_notify]

Hollenbeck, Scott 2009-04-14 14:14
> I'm reasonably certain
> that this is behavior that's typically buried in a toolkit instead of
> being implemented by an EPP developer, so perhaps that new text should
> be removed from the document.

I agree with you on that.

As James, I'm using a toolkit to deal with SSL stuff (a wrapper
around openssl called IO::Socket::SSL under Perl),
I do not know if it does a TLS_close_notify.
Per its documentation, it does do it properly, even warning not to do
a shutdown before a close has it needs to send this TLS notification
on proper shutdown.

Also, most of the time, the connection is first closed by the
server, after the client message.
A quick ssldump gives me:

1 8 0.2824 (0.0000) S>CV3.1(992) application_data
1 9 0.2967 (0.0142) C>SV3.1(768) application_data
1 10 0.3632 (0.0664) S>CV3.1(576) application_data
1 11 1.2652 (0.9020) C>SV3.1(336) application_data
1 12 1.3261 (0.0608) S>CV3.1(368) application_data
1 13 1.3261 (0.0000) S>CV3.1(32) Alert
1 1.3261 (0.0000) S>C TCP FIN
1 14 1.3275 (0.0013) C>SV3.1(32) Alert
1 1.3279 (0.0004) C>S TCP RST

The alerts are probably the close_notify.

--
Patrick Mevzek
Dot and Co

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 n3EBF1rX021913 for ; Tue, 14 Apr 2009 13:15:01 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n3EBF039027840 for ietf-provreg-outgoing; Tue, 14 Apr 2009 13:15:01 +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 n3EBExdn016573 for ; Tue, 14 Apr 2009 13:15:00 +0200 (MEST)
Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id n3EB6i9G030044 for ; Tue, 14 Apr 2009 07:06:44 -0400
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Apr 2009 07:14:59 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BCF2.3F1B6534"
Subject: RE: [ietf-provreg] AD Review Comments: draft-hollenbeck-rfc4934bis-00
Date: Tue, 14 Apr 2009 07:14:58 -0400
Message-ID: <[email-masked]>
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-provreg] AD Review Comments: draft-hollenbeck-rfc4934bis-00
Thread-Index: Acm8NJmzYO33/ZvpQjq+pbJCVGlx1QATEQdWABw02xA=
References: <[email-masked]>
From: "Hollenbeck, Scott"
To: "Gould, James" , "EPP Provreg"
X-OriginalArrivalTime: 14 Apr 2009 11:14:59.0229 (UTC) FILETIME=[3F9F6CD0:01C9BCF2]
Sender: [email-masked]
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9BCF2.3F1B6534
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

According to this reference:
=20
http://download.java.net/jdk7/docs/technotes/guides/security/jsse/JSSERe
fGuide.html
=20
it should, but I can't confirm that it does. I'm reasonably certain
that this is behavior that's typically buried in a toolkit instead of
being implemented by an EPP developer, so perhaps that new text should
be removed from the document.

-Scott-=20

=20

________________________________

From: Gould, James=20
Sent: Monday, April 13, 2009 5:43 PM
To: Hollenbeck, Scott; EPP Provreg
Subject: Re: [ietf-provreg] AD Review Comments:
draft-hollenbeck-rfc4934bis-00
=09
=09
Scott,
=09
We're implementing SSL using JSSE in our Java EPP SDK, but I'm
not sure if JSSE sends a TLS_close_notify alert before the connection is
closed. =20
=09
--=20
=09
=09
JG=20
=09
-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063
=09
=20
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166
=09
Notice to Recipient: This e-mail contains confidential,
proprietary and/or Registry Sensitive information intended solely for
the recipient and, thus may not be retransmitted, reproduced or
disclosed without the prior written consent of VeriSign Naming and
Directory Services. If you have received this e-mail message in error,
please notify the sender immediately by telephone or reply e-mail and
destroy the original message without making a copy. Thank you.
=09
=09
=09
________________________________

From: "Hollenbeck, Scott"
Date: Mon, 13 Apr 2009 08:37:25 -0400
To: EPP Provreg
Subject: [ietf-provreg] AD Review Comments:
draft-hollenbeck-rfc4934bis-00
=09
Some feedback from Alexey on the new TLS Usage Profile text in
4934bis.
I now need implementer feedback.
=09
>> A client MUST close the associated TLS connection if the
connection
>> is not expected to deliver any EPP messages later. It MUST
send a
>> TLS close_notify alert before closing the connection.
>>
> As an implementor I remain skeptical that existing
implementations do
> that. At least I doubt many IMAP or SMTP servers do that. So
maybe you
=09
> should check how existing EPP implementations handle
connection
closure.
=09
What are you implementers doing?
=09
> I think the text about how to extract and verify domain
information
from
> X.509 certificates is still missing from your draft. I think
that what
=09
> Chris wanted you to do and I am in agreement with him on this.
> I see some text on this in Section 8, but I think it is a bit
too
short.
> Check section 2.2.1 of draft-ietf-sieve-managesieve-09.txt. It
probably
> contains 80% of what EPP should use.
=09
Comments, please. I've sent a note to Alexey pushing back on
this
because (in my opinion) this puts mandates on client and server
certificate validation behavior that don't affect EPP
interoperability.
If I'm wrong, I'd prefer to cite an existing mature reference
instead of
cloning text from an unapproved I-D. Does anybody know of one?
=09
-Scott-
=09
=09
=09

------_=_NextPart_001_01C9BCF2.3F1B6534
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Re: [ietf-provreg] AD Review Comments: =
draft-hollenbeck-rfc4934bis-00

According to this =
reference:

http://download.java.net/jdk7/docs/technotes/guides/s=
ecurity/jsse/JSSERefGuide.html

it should, but I can't confirm that it =
does.  I'm=20
reasonably certain that this is behavior that's typically buried in a =
toolkit=20
instead of being implemented by an EPP developer, so perhaps that new =
text=20
should be removed from the document.

-Scott-

From: Gould, James =

Sent: Monday,=20
April 13, 2009 5:43 PM
To: Hollenbeck, Scott; EPP=20
Provreg
Subject: Re: [ietf-provreg] AD Review Comments:=20
draft-hollenbeck-rfc4934bis-00

Scott,

We’re implementing SSL =
using JSSE in our=20
Java EPP SDK, but I’m not sure if JSSE sends a TLS_close_notify =
alert before=20
the connection is closed.

--=20

JG

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

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

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

From: "Hollenbeck, Scott" <[email-masked]>
=
Date:=20
Mon, 13 Apr 2009 08:37:25 -0400
To: EPP Provreg <[email-masked]>
Subjec=
t:=20
[ietf-provreg] AD Review Comments:=20
draft-hollenbeck-rfc4934bis-00

Some feedback from Alexey on the =
new TLS=20
Usage Profile text in 4934bis.
I now need implementer=20
feedback.

>>  A client MUST close the associated TLS =

connection if the connection
>>  is not expected to =
deliver any=20
EPP messages later.  It MUST send a
>>  TLS =
close_notify=20
alert before closing the connection.
> As an =
implementor I=20
remain skeptical that existing implementations do
> that. At =
least I=20
doubt many IMAP or SMTP servers do that. So maybe you

> =
should check=20
how existing EPP implementations handle =
connection
closure.

What are=20
you implementers doing?

> I think the text about how to =
extract and=20
verify domain information
from
> X.509 certificates is still =
missing=20
from your draft. I think that what

> Chris wanted you to do =
and I am=20
in agreement with him on this.
> I see some text on this in =
Section 8,=20
but I think it is a bit too
short.
> Check section 2.2.1 of=20
draft-ietf-sieve-managesieve-09.txt. It
probably
> contains =
80% of=20
what EPP should use.

Comments, please.  I've sent a note =
to Alexey=20
pushing back on this
because (in my opinion) this puts mandates on =
client=20
and server
certificate validation behavior that don't affect EPP=20
interoperability.
If I'm wrong, I'd prefer to cite an existing =
mature=20
reference instead of
cloning text from an unapproved I-D. =
Does=20
anybody know of=20
one?

-Scott-

------_=_NextPart_001_01C9BCF2.3F1B6534--

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 n3DLnivq012724 for ; Mon, 13 Apr 2009 23:49:44 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n3DLniBS009863 for ietf-provreg-outgoing; Mon, 13 Apr 2009 23:49:44 +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 n3DLnh5A005506 for ; Mon, 13 Apr 2009 23:49:44 +0200 (MEST)
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 n3DLfT6b031155 for ; Mon, 13 Apr 2009 17:41:29 -0400
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Apr 2009 17:49:42 -0400
Received: from 10.131.29.236 ([10.131.29.236]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Mon, 13 Apr 2009 21:43:24 +0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Mon, 13 Apr 2009 17:43:22 -0400
Subject: Re: [ietf-provreg] AD Review Comments: draft-hollenbeck-rfc4934bis-00
From: James Gould
To: "Hollenbeck, Scott" , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] AD Review Comments: draft-hollenbeck-rfc4934bis-00
Thread-Index: Acm8NJmzYO33/ZvpQjq+pbJCVGlx1QATEQdW
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3322489403_26622019"
X-OriginalArrivalTime: 13 Apr 2009 21:49:42.0559 (UTC) FILETIME=[C0A4AAF0:01C9BC81]
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_3322489403_26622019
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Scott,

We=B9re implementing SSL using JSSE in our Java EPP SDK, but I=B9m not sure if
JSSE sends a TLS_close_notify alert before the connection is closed.

--=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: "Hollenbeck, Scott"
Date: Mon, 13 Apr 2009 08:37:25 -0400
To: EPP Provreg
Subject: [ietf-provreg] AD Review Comments: draft-hollenbeck-rfc4934bis-00

Some feedback from Alexey on the new TLS Usage Profile text in 4934bis.
I now need implementer feedback.

>> A client MUST close the associated TLS connection if the connection
>> is not expected to deliver any EPP messages later. It MUST send a
>> TLS close_notify alert before closing the connection.
>>
> As an implementor I remain skeptical that existing implementations do
> that. At least I doubt many IMAP or SMTP servers do that. So maybe you

> should check how existing EPP implementations handle connection
closure.

What are you implementers doing?

> I think the text about how to extract and verify domain information
from
> X.509 certificates is still missing from your draft. I think that what

> Chris wanted you to do and I am in agreement with him on this.
> I see some text on this in Section 8, but I think it is a bit too
short.
> Check section 2.2.1 of draft-ietf-sieve-managesieve-09.txt. It
probably
> contains 80% of what EPP should use.

Comments, please. I've sent a note to Alexey pushing back on this
because (in my opinion) this puts mandates on client and server
certificate validation behavior that don't affect EPP interoperability.
If I'm wrong, I'd prefer to cite an existing mature reference instead of
cloning text from an unapproved I-D. Does anybody know of one?

-Scott-

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

Re: [ietf-provreg] AD Review Comments: draft-hollenbeck-rfc4934bis-0=
0

Scott,

We’re implementing SSL using JSSE in our Java EPP SDK, but I’m =
not sure if JSSE sends a TLS_close_notify alert before the connection is clo=
sed.

--

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: "Hollenbeck, Scott&=
quot; <[email-masked]>=
;

Date: Mon, 13 Apr 2009 08:37:25 -0400

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

Subject: [ietf-provreg] AD Review Comments: draft-hollenbeck-rfc4934=
bis-00

Some feedback from Alexey on the new TLS Usage Profile text in 4934bis.

I now need implementer feedback.

>>  A client MUST close the associated TLS connection if the con=
nection

>>  is not expected to deliver any EPP messages later.  It =
MUST send a

>>  TLS close_notify alert before closing the connection.

> As an implementor I remain skeptical that existing implementations do<=
BR>
> that. At least I doubt many IMAP or SMTP servers do that. So maybe you=

> should check how existing EPP implementations handle connection

closure.

What are you implementers doing?

> I think the text about how to extract and verify domain information
from

> X.509 certificates is still missing from your draft. I think that what=

> Chris wanted you to do and I am in agreement with him on this.

> I see some text on this in Section 8, but I think it is a bit too

short.

> Check section 2.2.1 of draft-ietf-sieve-managesieve-09.txt. It

probably

> contains 80% of what EPP should use.

Comments, please.  I've sent a note to Alexey pushing back on this

because (in my opinion) this puts mandates on client and server

certificate validation behavior that don't affect EPP interoperability.

If I'm wrong, I'd prefer to cite an existing mature reference instead of
cloning text from an unapproved I-D.  Does anybody know of one?

-Scott-

--B_3322489403_26622019--

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 n3DCbTDp025580 for ; Mon, 13 Apr 2009 14:37:29 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n3DCbS0T023967 for ietf-provreg-outgoing; Mon, 13 Apr 2009 14:37:29 +0200 (MEST)
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 n3DCbSB2015312 for ; Mon, 13 Apr 2009 14:37:28 +0200 (MEST)
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 n3DCSJ7g019719 for ; Mon, 13 Apr 2009 08:28:19 -0400
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, 13 Apr 2009 13:37:26 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [ietf-provreg] AD Review Comments: draft-hollenbeck-rfc4934bis-00
Date: Mon, 13 Apr 2009 08:37:25 -0400
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: AD Review Comments: draft-hollenbeck-rfc4934bis-00
Thread-Index: Acm8NJmzYO33/ZvpQjq+pbJCVGlx1Q==
From: "Hollenbeck, Scott"
To:
X-OriginalArrivalTime: 13 Apr 2009 12:37:26.0254 (UTC) FILETIME=[99DDC8E0:01C9BC34]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n3DCbSB2015295
Sender: [email-masked]
Precedence: bulk

Some feedback from Alexey on the new TLS Usage Profile text in 4934bis.
I now need implementer feedback.

>> A client MUST close the associated TLS connection if the connection
>> is not expected to deliver any EPP messages later. It MUST send a
>> TLS close_notify alert before closing the connection.
>>
> As an implementor I remain skeptical that existing implementations do
> that. At least I doubt many IMAP or SMTP servers do that. So maybe you

> should check how existing EPP implementations handle connection
closure.

What are you implementers doing?

> I think the text about how to extract and verify domain information
from
> X.509 certificates is still missing from your draft. I think that what

> Chris wanted you to do and I am in agreement with him on this.
> I see some text on this in Section 8, but I think it is a bit too
short.
> Check section 2.2.1 of draft-ietf-sieve-managesieve-09.txt. It
probably
> contains 80% of what EPP should use.

Comments, please. I've sent a note to Alexey pushing back on this
because (in my opinion) this puts mandates on client and server
certificate validation behavior that don't affect EPP interoperability.
If I'm wrong, I'd prefer to cite an existing mature reference instead of
cloning text from an unapproved I-D. Does anybody know of one?

-Scott-

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n36H8S6N002935 for ; Mon, 6 Apr 2009 19:08:28 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n36H8Sbb000095 for ietf-provreg-outgoing; Mon, 6 Apr 2009 19:08:28 +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 n36H8Rul017881 for ; Mon, 6 Apr 2009 19:08:27 +0200 (MEST)
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 n36H0RtY028923 for ; Mon, 6 Apr 2009 13:00:27 -0400
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 13:08:26 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9B6DA.4C0DDFB9"
Subject: [ietf-provreg] FW: I-D Action:draft-hollenbeck-rfc4931bis-00.txt
Date: Mon, 6 Apr 2009 13:08:23 -0400
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: I-D Action:draft-hollenbeck-rfc4931bis-00.txt
Thread-Index: Acm210MOopZqEhKcS6mHh5OSSxNWjQAAv7BA
From: "Hollenbeck, Scott"
To:
X-OriginalArrivalTime: 06 Apr 2009 17:08:26.0647 (UTC) FILETIME=[4CEC9A70:01C9B6DA]
Sender: [email-masked]
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9B6DA.4C0DDFB9
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, April 06, 2009 12:45 PM
To: [email-masked]
Subject: I-D Action:draft-hollenbeck-rfc4931bis-00.txt=20

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

Title : Extensible Provisioning Protocol (EPP) Domain
Name Mapping
Author(s) : S. Hollenbeck
Filename : draft-hollenbeck-rfc4931bis-00.txt
Pages : 44
Date : 2009-04-06

This document describes an Extensible Provisioning Protocol (EPP)
mapping for the provisioning and management of Internet domain names
stored in a shared central repository. Specified in XML, the mapping
defines EPP command syntax and semantics as applied to domain names.
This document is intended to obsolete RFC 4931.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------_=_NextPart_001_01C9B6DA.4C0DDFB9
Content-Type: application/octet-stream;
name="draft-hollenbeck-rfc4931bis-00.URL"
Content-Transfer-Encoding: base64
Content-Description: draft-hollenbeck-rfc4931bis-00.URL
Content-Disposition: attachment;
filename="draft-hollenbeck-rfc4931bis-00.URL"

W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1ob2xsZW5iZWNrLXJmYzQ5MzFiaXMtMDAudHh0DQo=

------_=_NextPart_001_01C9B6DA.4C0DDFB9--

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 n36FItpc012396 for ; Mon, 6 Apr 2009 17:18:55 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n36FItLc007564 for ietf-provreg-outgoing; Mon, 6 Apr 2009 17:18:55 +0200 (MEST)
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 n36FIsT2002635 for ; Mon, 6 Apr 2009 17:18:54 +0200 (MEST)
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 n36FA0A3004680 for ; Mon, 6 Apr 2009 11:10:00 -0400
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 11:18:53 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9B6CA.FF0E300B"
Subject: [ietf-provreg] FW: I-D Action:draft-hollenbeck-rfc4934bis-00.txt
Date: Mon, 6 Apr 2009 11:18:56 -0400
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: I-D Action:draft-hollenbeck-rfc4934bis-00.txt
Thread-Index: Acm2yWO0E3lZEEuGSrWu3yC5nfxgnQAAZW8g
From: "Hollenbeck, Scott"
To:
X-OriginalArrivalTime: 06 Apr 2009 15:18:53.0976 (UTC) FILETIME=[FF4E9980:01C9B6CA]
Sender: [email-masked]
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9B6CA.FF0E300B
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, April 06, 2009 11:00 AM
To: [email-masked]
Subject: I-D Action:draft-hollenbeck-rfc4934bis-00.txt=20

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

Title : Extensible Provisioning Protocol (EPP)
Transport over TCP
Author(s) : S. Hollenbeck
Filename : draft-hollenbeck-rfc4934bis-00.txt
Pages : 11
Date : 2009-04-06

This document describes how an Extensible Provisioning Protocol (EPP)
session is mapped onto a single Transmission Control Protocol (TCP)
connection. This mapping requires use of the Transport Layer Security
(TLS) protocol to protect information exchanged between an EPP client
and an EPP server. This document is intended to obsolete RFC 4934.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------_=_NextPart_001_01C9B6CA.FF0E300B
Content-Type: application/octet-stream;
name="draft-hollenbeck-rfc4934bis-00.URL"
Content-Transfer-Encoding: base64
Content-Description: draft-hollenbeck-rfc4934bis-00.URL
Content-Disposition: attachment;
filename="draft-hollenbeck-rfc4934bis-00.URL"

W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1ob2xsZW5iZWNrLXJmYzQ5MzRiaXMtMDAudHh0DQo=

------_=_NextPart_001_01C9B6CA.FF0E300B--

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 n36FIbIU016361 for ; Mon, 6 Apr 2009 17:18:37 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n36FIb3J006616 for ietf-provreg-outgoing; Mon, 6 Apr 2009 17:18:37 +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 n36FIa9Y023150 for ; Mon, 6 Apr 2009 17:18:36 +0200 (MEST)
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 n36FAaVJ022906 for ; Mon, 6 Apr 2009 11:10:36 -0400
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 11:18:35 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9B6CA.F428C791"
Subject: [ietf-provreg] FW: I-D Action:draft-hollenbeck-rfc4933bis-00.txt
Date: Mon, 6 Apr 2009 11:18:38 -0400
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: I-D Action:draft-hollenbeck-rfc4933bis-00.txt
Thread-Index: Acm2yQLu+QqfzaZmQMW3hNnLTCVSvQAAew2A
From: "Hollenbeck, Scott"
To:
X-OriginalArrivalTime: 06 Apr 2009 15:18:35.0617 (UTC) FILETIME=[F45D3D10:01C9B6CA]
Sender: [email-masked]
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9B6CA.F428C791
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, April 06, 2009 11:00 AM
To: [email-masked]
Subject: I-D Action:draft-hollenbeck-rfc4933bis-00.txt=20

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

Title : Extensible Provisioning Protocol (EPP) Contact
Mapping
Author(s) : S. Hollenbeck
Filename : draft-hollenbeck-rfc4933bis-00.txt
Pages : 41
Date : 2009-04-06

This document describes an Extensible Provisioning Protocol (EPP)
mapping for the provisioning and management of individual or
organizational social information identifiers (known as "contacts")
stored in a shared central repository. Specified in Extensible Markup
Language (XML), the mapping defines EPP command syntax and semantics as
applied to contacts. This document is intended to obsolete RFC 4933.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------_=_NextPart_001_01C9B6CA.F428C791
Content-Type: application/octet-stream;
name="draft-hollenbeck-rfc4933bis-00.URL"
Content-Transfer-Encoding: base64
Content-Description: draft-hollenbeck-rfc4933bis-00.URL
Content-Disposition: attachment;
filename="draft-hollenbeck-rfc4933bis-00.URL"

W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1ob2xsZW5iZWNrLXJmYzQ5MzNiaXMtMDAudHh0DQo=

------_=_NextPart_001_01C9B6CA.F428C791--

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 n36FIMgo000887 for ; Mon, 6 Apr 2009 17:18:22 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n36FIMKI002797 for ietf-provreg-outgoing; Mon, 6 Apr 2009 17:18:22 +0200 (MEST)
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 n36FILAY004566 for ; Mon, 6 Apr 2009 17:18:22 +0200 (MEST)
Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id n36F9Q5O004661 for ; Mon, 6 Apr 2009 11:09:27 -0400
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 11:18:21 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9B6CA.EB43F47A"
Subject: [ietf-provreg] FW: I-D Action:draft-hollenbeck-rfc4932bis-00.txt
Date: Mon, 6 Apr 2009 11:18:23 -0400
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: I-D Action:draft-hollenbeck-rfc4932bis-00.txt
Thread-Index: Acm2yJ8bvcjEyNYnStyzETIFxwAhVgAAjYoA
From: "Hollenbeck, Scott"
To:
X-OriginalArrivalTime: 06 Apr 2009 15:18:21.0049 (UTC) FILETIME=[EBAE5690:01C9B6CA]
Sender: [email-masked]
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9B6CA.EB43F47A
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, April 06, 2009 11:00 AM
To: [email-masked]
Subject: I-D Action:draft-hollenbeck-rfc4932bis-00.txt=20

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

Title : Extensible Provisioning Protocol (EPP) Host
Mapping
Author(s) : S. Hollenbeck
Filename : draft-hollenbeck-rfc4932bis-00.txt
Pages : 29
Date : 2009-04-06

This document describes an Extensible Provisioning Protocol (EPP)
mapping for the provisioning and management of Internet host names
stored in a shared central repository. Specified in XML, the mapping
defines EPP command syntax and semantics as applied to host names.
This document is intended to obsolete RFC 4932.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------_=_NextPart_001_01C9B6CA.EB43F47A
Content-Type: application/octet-stream;
name="draft-hollenbeck-rfc4932bis-00.URL"
Content-Transfer-Encoding: base64
Content-Description: draft-hollenbeck-rfc4932bis-00.URL
Content-Disposition: attachment;
filename="draft-hollenbeck-rfc4932bis-00.URL"

W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1ob2xsZW5iZWNrLXJmYzQ5MzJiaXMtMDAudHh0DQo=

------_=_NextPart_001_01C9B6CA.EB43F47A--

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 n347Yqc8012374 for ; Sat, 4 Apr 2009 09:34:52 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n347YqGO012612 for ietf-provreg-outgoing; Sat, 4 Apr 2009 09:34:52 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n347Yple012925 for ; Sat, 4 Apr 2009 09:34:51 +0200 (MEST)
X-Files: PGP.sig : 186
X-IronPort-AV: E=Sophos;i="4.39,323,1235952000"; d="sig'?scan'208";a="33040270"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-4.cisco.com with ESMTP; 04 Apr 2009 07:34:48 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n347Ym7n000710; Sat, 4 Apr 2009 09:34:48 +0200
Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n347YmYO019275; Sat, 4 Apr 2009 07:34:48 GMT
Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 4 Apr 2009 09:34:48 +0200
Received: from [192.168.1.95] ([10.61.97.174]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 4 Apr 2009 09:34:47 +0200
Cc: "Hollenbeck, Scott" , , EPP Provreg
Message-Id: <[email-masked]>
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=
To: James Gould
In-Reply-To:
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-68-677765284"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs
Date: Sat, 4 Apr 2009 09:34:46 +0200
References:
X-Pgp-Agent: GPGMail d55 (v55, Leopard)
X-Mailer: Apple Mail (2.930.3)
X-OriginalArrivalTime: 04 Apr 2009 07:34:47.0632 (UTC) FILETIME=[D4C43500:01C9B4F7]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3821; t=1238830488; x=1239694488; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[email-masked]; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20
|Subject:=20Re=3A=20[ietf-provreg]=20RE=3A=20Standards=20Tr ack=20Advancement=20Request=20for=20EPP=20RFCs |Sender:=20; bh=PM4XSg9SyTJG0C8w0gnhzzxSVnWmKtr14WX/V5j6sCc=; b=mALOpLofXXZYgxGekle97dp+nAO8LpXnq6x0MZBG8gIuczg3kmW8aXZ8hj e6qy3wzaf0zLSZ0K293Sp30wbOFmAfxD4xdEfMrRcrNhh90TUqsWo9M0r+kH k8dJ1B6Elp;
Authentication-Results: ams-dkim-2; header.From=[email-masked]; dkim=pass ( sig from cisco.com/amsdkim2001 verified; );
Sender: [email-masked]
Precedence: bulk

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-68-677765284
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable

On 3 apr 2009, at 15.30, James Gould wrote:

> Interesting that there is another model that you're taking for =20
> external
> hosts. So to summarize, the following models exist for the =20
> management of
> external hosts:
>
> 1. External hosts don=92t have a sponsoring client, meaning once they =20=

> are
> created they can=92t be modified. This sounds like the model taken =20=

> by .se.

We should at the same time remember that they do not have to be =20
modified.

> 2. Each Registrar has its own set of external hosts that can be
> independently managed by the Registrar. This is what was defined in =20=

> an
> earlier version of the EPP, which was implemented by .name.

Ok

> 3. There is one set of external hosts for the Registry with the =20
> client that
> created them as the sponsoring client. The sponsoring client can =20
> update
> the external host independent references to the host by domains. The
> external host can not be deleted if it=92s being used as a delegating =20=

> name
> server of a domain. This is what is implemented in .com and .net.
>
> Are there any other models implemented by Registries?

I can also envision you do not need host objects for external hosts.

> RFC 4932 sort of indicates that external hosts do have a sponsoring =20=

> client,
> so that could be a conflict with model #1. RFC 4932 does not =20
> prohibit model
> #2, but model #2 does not seem to be very popular with the =20
> Registrars. RFC
> 4932 has the verbiage =93changing an external host object that has
> associations with objects that are sponsored by a different client. =20=

> changing
> an external host object that has associations with objects that are
> sponsored by a different client. Attempts to update such hosts =20
> directly MUST
> fail with EPP error code 2305. The change can be provisioned by =20
> creating a
> new external host with a new name and needed new attributes and =20
> subsequently
> updating the other objects sponsored by the client. This verbiage =20
> really
> applies to model #3, but it doesn=92t sound like any Registries =20
> implementing
> model #3 have implemented to this verbiage. Changing to this model =20=

> for .com
> and .net would have major issues with Registrars, since they don=92t =20=

> seem to
> be a big fan of model #2 and a modified model #3 according to RFC 4932
> represents a huge management burden for changing external hosts.
>
> If there is an opportunity to change the wording, I would prefer to =20=

> change
> the MUST to a SHOULD in the RFC 4932 paragraph as shown below to =20
> support
> existing implementations and to not require this behavior.
>
>> changing an external host object that has associations with objects =20=

>> that are
>> sponsored by a different client. Attempts to update such hosts =20
>> directly SHOULD
>> fail with EPP error code 2305. The change can be provisioned by =20
>> creating a new
>> external host with a new name and needed new attributes and =20
>> subsequently
>> updating the other objects sponsored by the client.

Patrik

--Apple-Mail-68-677765284
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iD8DBQFJ1w2WvHlR2X0luNwRAmtNAKC+W99WQKbPE8e7gmp+HU7X/v7yqQCguOfp
VYlkJbQGRO1V34hViKR80V4=
=PMGE
-----END PGP SIGNATURE-----

--Apple-Mail-68-677765284--

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 n33JAXd3028717 for ; Fri, 3 Apr 2009 21:10:33 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n33JAX8u012050 for ietf-provreg-outgoing; Fri, 3 Apr 2009 21:10:33 +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 n33JAW7m013683 for ; Fri, 3 Apr 2009 21:10:33 +0200 (MEST)
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 n33J2bEO032731 for ; Fri, 3 Apr 2009 15:02:37 -0400
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 15:10:31 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9B48F.DBA06B5C"
Subject: [ietf-provreg] FW: I-D Action:draft-hollenbeck-rfc4930bis-00.txt
Date: Fri, 3 Apr 2009 15:10:30 -0400
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: I-D Action:draft-hollenbeck-rfc4930bis-00.txt
Thread-Index: Acm0jIHycxO44i8GTMe1IMF5iVIjQwAA0PMQ
From: "Hollenbeck, Scott"
To:
X-OriginalArrivalTime: 03 Apr 2009 19:10:31.0762 (UTC) FILETIME=[DBCB3320:01C9B48F]
Sender: [email-masked]
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9B48F.DBA06B5C
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

FYI - other updates coming "soon".

-Scott-

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, April 03, 2009 2:45 PM
To: [email-masked]
Subject: I-D Action:draft-hollenbeck-rfc4930bis-00.txt=20

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

Title : Extensible Provisioning Protocol (EPP)
Author(s) : S. Hollenbeck
Filename : draft-hollenbeck-rfc4930bis-00.txt
Pages : 69
Date : 2009-04-03

This document describes an application layer client-server protocol for
the provisioning and management of objects stored in a shared central
repository. Specified in XML, the protocol defines generic object
management operations and an extensible framework that maps protocol
operations to objects. This document includes a protocol specification,
an object mapping template, and an XML media type registration. This
document is intended to obsolete RFC 4930.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------_=_NextPart_001_01C9B48F.DBA06B5C
Content-Type: application/octet-stream;
name="draft-hollenbeck-rfc4930bis-00.URL"
Content-Transfer-Encoding: base64
Content-Description: draft-hollenbeck-rfc4930bis-00.URL
Content-Disposition: attachment;
filename="draft-hollenbeck-rfc4930bis-00.URL"

W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1ob2xsZW5iZWNrLXJmYzQ5MzBiaXMtMDAudHh0DQo=

------_=_NextPart_001_01C9B48F.DBA06B5C
Content-Type: text/plain;
name="ATT1606388.txt"
Content-Transfer-Encoding: base64
Content-Description: ATT1606388.txt
Content-Disposition: attachment;
filename="ATT1606388.txt"

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v
dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj
dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0
Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K

------_=_NextPart_001_01C9B48F.DBA06B5C--

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 n33DUeZu012946 for ; Fri, 3 Apr 2009 15:30:40 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n33DUe64011641 for ietf-provreg-outgoing; Fri, 3 Apr 2009 15:30:40 +0200 (MEST)
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 n33DUdnN017624 for ; Fri, 3 Apr 2009 15:30:39 +0200 (MEST)
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 n33DLnvd029951; Fri, 3 Apr 2009 09:21:49 -0400
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 09:30:37 -0400
Received: from 10.131.29.236 ([10.131.29.236]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Fri, 3 Apr 2009 13:30:36 +0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Fri, 03 Apr 2009 09:30:34 -0400
Subject: Re: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs
From: James Gould
To: Patrik =?ISO-8859-1?B?RuRsdHN0cvZt?=
CC: "Hollenbeck, Scott" , , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs
Thread-Index: AcmzwVS4Xee0wk2/Rl+HluSWkdSZnQAnwkOw
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3321595835_12773598"
X-OriginalArrivalTime: 03 Apr 2009 13:30:37.0032 (UTC) FILETIME=[5F965E80:01C9B460]
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_3321595835_12773598
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Patrik,

Interesting that there is another model that you're taking for external
hosts. So to summarize, the following models exist for the management of
external hosts:

1. External hosts don=B9t have a sponsoring client, meaning once they are
created they can=B9t be modified. This sounds like the model taken by .se.
2. Each Registrar has its own set of external hosts that can be
independently managed by the Registrar. This is what was defined in an
earlier version of the EPP, which was implemented by .name.
3. There is one set of external hosts for the Registry with the client that
created them as the sponsoring client. The sponsoring client can update
the external host independent references to the host by domains. The
external host can not be deleted if it=B9s being used as a delegating name
server of a domain. This is what is implemented in .com and .net.

Are there any other models implemented by Registries?

RFC 4932 sort of indicates that external hosts do have a sponsoring client,
so that could be a conflict with model #1. RFC 4932 does not prohibit mode=
l
#2, but model #2 does not seem to be very popular with the Registrars. RFC
4932 has the verbiage =B3changing an external host object that has
associations with objects that are sponsored by a different client. changin=
g
an external host object that has associations with objects that are
sponsored by a different client. Attempts to update such hosts directly MUS=
T
fail with EPP error code 2305. The change can be provisioned by creating a
new external host with a new name and needed new attributes and subsequentl=
y
updating the other objects sponsored by the client. This verbiage really
applies to model #3, but it doesn=B9t sound like any Registries implementing
model #3 have implemented to this verbiage. Changing to this model for .co=
m
and .net would have major issues with Registrars, since they don=B9t seem to
be a big fan of model #2 and a modified model #3 according to RFC 4932
represents a huge management burden for changing external hosts.

If there is an opportunity to change the wording, I would prefer to change
the MUST to a SHOULD in the RFC 4932 paragraph as shown below to support
existing implementations and to not require this behavior.

> changing an external host object that has associations with objects that =
are
> sponsored by a different client. Attempts to update such hosts directly S=
HOULD
> fail with EPP error code 2305. The change can be provisioned by creating =
a new
> external host with a new name and needed new attributes and subsequently
> updating the other objects sponsored by the client.

--=20

JG=20

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

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

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

> From: Patrik F=E4ltstr=F6m
> Date: Thu, 2 Apr 2009 14:31:52 -0400
> To: James Gould
> Cc: "Hollenbeck, Scott" , ,
> EPP Provreg
> Subject: Re: [ietf-provreg] RE: Standards Track Advancement Request for E=
PP
> RFCs
>=20
> On 2 apr 2009, at 19.30, James Gould wrote:
>=20
>> JG =AD You are referring to internal hosts that are subordinate to a
>> domain in
>> the case of the host ns.foo.se and domain foo.se, but how do you
>> handle
>> external hosts like ns.bar.net that is not subordinate to any domain
>> in .se?
>> In our Registries, child hosts of a domain (ns.foo.se for foo.se)
>> are also
>> transferred along with the domain and the sponsoring client must be
>> the
>> same. Since there is no parent domain for an external host
>> (ns.bar.net in
>> .se) you can=B9t include the same type of validation. The
>> specification says
>> that =B3changing an external host object that has associations with
>> objects
>> that are sponsored by a different client should result in a EPP
>> error code
>> 2305=B2, which means that if one client references an external host
>> sponsored
>> by a different client, that the host can not be changed. Does this
>> apply to
>> any change or just a change like changing the host name? This
>> statement
>> means for a Registry with many domains and external hosts, that
>> there is
>> much more work required by the sponsoring client to create a new
>> host and
>> update all of their domains that link to the host to reference the
>> new host.
>> Implementing this represents a substantial change to the way that
>> Registrars
>> manage external hosts, at least in our Registries, unless the first
>> approach
>> is implemented where each client has it=B9s own list of external
>> hosts. The
>> .name Registry implements the first option.
>=20
> .SE transfer the host object together with the domain it belongs to.
> host objects outside of .se have no sponsoring clients.
>=20
> That is the explanation (and there are no more words), and when
> reverse engineering what has actually been implemented, I found that
> the best I can do is to always try to create the host object when I
> have some operation to do on a domain object, and more or less ignore
> the error code...
>=20
> Not fun, but there are tons of similar situations (regarding
> validation of attribute values) that also lack documentation (and lack
> of specification in the epp spec), so "to make things work", there is
> a lot of "trial and error" in the actual algorithm implemented on top
> of the epp protocol.
>=20
>>> So what I call "cloning" is then something the gaining registrar have
>>> to do manually? Do you separate those changes of holder from a
>>> "normal" change of holder, i.e. restart the payment cycle etc? Do you
>>> keep track of the now two contact records be the "same" contact be
>>> represented by two records? You as registry that is.
>>=20
>> JG - Yes, if the Registrar wants to update the contact information
>> linked
>> by the domain than they have to either request a transfer of the
>> contacts or
>> manually create or reuse an existing contact record to link to the
>> domain.
>> Updating the transferred domain to reference new contact data is
>> handled in
>> the same way as any domain update. There is no side effects
>> associated with
>> billing, since the billable action was transferring the domain and the
>> contact information can be changed at any time.
>=20
> In .SE there is a difference. Changing the holder do have legal
> impact, and the registry require paperwork etc. So changing that
> attribute value is a "special" operation. What is interesting though
> is that .SE is themselves as registry cloning the holder and updates
> the holderid when a transfer happens. That implies that if you track
> domains in .SE, you will see a change of holder(-id) when a transfer
> happens even though there was no change in holder. Yes, that implies
> creation of many many many contact objects over time. Contacts have to
> be deleted manually by the registrar.
>=20
> I do not like it, but that is how they have implemented contacts.
>=20
> Patrik
>=20

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

Re: [ietf-provreg] RE: Standards Track Advancement Request for EPP R=
FCs

Patrik,

Interesting that there is another model that you're taking for external hos=
ts.  So to summarize, the following models exist for the management of =
external hosts:

External hosts don’t have a sponsoring client,=
meaning once they are created they can’t be modified.  This soun=
ds like the model taken by .se.

Each Registrar has its own set of external hosts that ca=
n be independently managed by the Registrar.  This is what was defined =
in an earlier version of the EPP, which was implemented by .name.

There is one set of external hosts for the Registry with=
the client that created them as the sponsoring client.   The spon=
soring client can update the external host independent references to the hos=
t by domains.  The external host can not be deleted if it’s being=
used as a delegating name server of a domain.  This is what is impleme=
nted in .com  and .net.

Are there any other models implemented by Registries?

RFC 4932 sort of indicates that external hosts do have a sponsoring client,=
so that could be a conflict with model #1.  RFC 4932 does not prohibit=
model #2, but model #2 does not seem to be very popular with the Registrars=
.  RFC 4932 has the verbiage “changing an external host object th=
at has associations with objects that are sponsored by a different client. c=
hanging an external host object that has associations with objects that are =
sponsored by a different client. Attempts to update such hosts directly M=
UST fail with EPP error code 2305. The change can be provisioned by crea=
ting a new external host with a new name and needed new attributes and subse=
quently updating the other objects sponsored by the client.  This verbi=
age really applies to model #3, but it doesn’t sound like any Registri=
es implementing model #3 have implemented to this verbiage.  Changing t=
o this model for .com and .net would have major issues with Registrars, sinc=
e they don’t seem to be a big fan of model #2 and a modified model #3 =
according to RFC 4932 represents a huge management burden for changing exter=
nal hosts.

If there is an opportunity to change the wording, I would prefer to change =
the MUST to a SHOULD in the RFC 4932 paragraph as shown below to support exi=
sting implementations and to not require this behavior.

<=
SPAN STYLE=3D'font-size:11pt'>changing an external host object that has associ=
ations with objects that are sponsored by a different client. Attempts to up=
date such hosts directly SHOULD fail wit=
h EPP error code 2305. The change can be provisioned by creating a new exter=
nal host with a new name and needed new attributes and subsequently updating=
the other objects sponsored by the client.

=

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

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

> From: Patrik Fältström <[email-masked]>

> Date: Thu, 2 Apr 2009 14:31:52 -0400

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

> Cc: "Hollenbeck, Scott" <[email-masked]>, <Chri=
[email-masked]>,

> EPP Provreg <[email-masked]<=
/a>>

> Subject: Re: [ietf-provreg] RE: Standards Track Advancement Request fo=
r EPP

> RFCs

> On 2 apr 2009, at 19.30, James Gould wrote:

>> JG – You are referring to inter=
nal hosts that are subordinate to a

>> domain in

>> the case of the host ns.foo.se and domain foo.se, but how do you &=
nbsp;

>> handle

>> external hosts like ns.bar.net that is not subordinate to any doma=
in

>> in .se?

>> In our Registries, child hosts of a domain (ns.foo.se for foo.se) =

>> are also

>> transferred along with the domain and the sponsoring client must b=
e

>> the

>> same.  Since there is no parent domain for an external host &=
nbsp;

>> (ns.bar.net in

>> .se) you can’t include the same type of validation.  Th=
e

>> specification says

>> that “changing an external host object that has associations=
with

>> objects

>> that are sponsored by a different client should result in a EPP &n=
bsp;

>> error code

>> 2305”, which means that if one client references an external=
host

>> sponsored

>> by a different client, that the host can not be changed.  Doe=
s this

>> apply to

>> any change or just a change like changing the host name?  Thi=
s

>> statement

>> means for a Registry with many domains and external hosts, that &n=
bsp;

>> there is

>> much more work required by the sponsoring client to create a new &=
nbsp;

>> host and

>> update all of their domains that link to the host to reference the=

>> new host.

>> Implementing this represents a substantial change to the way that =

>> Registrars

>> manage external hosts, at least in our Registries, unless the firs=
t

>> approach

>> is implemented where each client has it’s own list of extern=
al

>> hosts.  The

>> .name Registry implements the first option.

> .SE transfer the host object together with the domain it belongs to. &=
nbsp;

> host objects outside of .se have no sponsoring clients.

> That is the explanation (and there are no more words), and when  =

> reverse engineering what has actually been implemented, I found that &=
nbsp;

> the best I can do is to always try to create the host object when I &n=
bsp;

> have some operation to do on a domain object, and more or less ignore =

> the error code...

> Not fun, but there are tons of similar situations (regarding
> validation of attribute values) that also lack documentation (and lack=

> of specification in the epp spec), so "to make things work",=
there is

> a lot of "trial and error" in the actual algorithm implement=
ed on top

> of the epp protocol.

>>> So what I call "cloning"=
; is then something the gaining registrar have

>>> to do manually? Do you separate those changes of holder from a=

>>> "normal" change of holder, i.e. restart the payment =
cycle etc? Do you

>>> keep track of the now two contact records be the "same&qu=
ot; contact be

>>> represented by two records? You as registry that is.

>> JG -  Yes, if the Registrar wants to update the contact infor=
mation

>> linked

>> by the domain than they have to either request a transfer of the &=
nbsp;

>> contacts or

>> manually create or reuse an existing contact record to link to the=

>> domain.

>> Updating the transferred domain to reference new contact data is &=
nbsp;

>> handled in

>> the same way as any domain update.  There is no side effects =

>> associated with

>> billing, since the billable action was transferring the domain and=
the

>> contact information can be changed at any time.

> In .SE there is a difference. Changing the holder do have legal  =

> impact, and the registry require paperwork etc. So changing that  =
;

> attribute value is a "special" operation. What is interestin=
g though

> is that .SE is themselves as registry cloning the holder and updates &=
nbsp;

> the holderid when a transfer happens. That implies that if you track &=
nbsp;

> domains in .SE, you will see a change of holder(-id) when a transfer &=
nbsp;

> happens even though there was no change in holder. Yes, that implies &=
nbsp;

> creation of many many many contact objects over time. Contacts have to=

> be deleted manually by the registrar.

> I do not like it, but that is how they have implemented contacts.

>     Patrik

--B_3321595835_12773598--

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 n32MeJwt005000 for ; Fri, 3 Apr 2009 00:40:19 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n32MeJ28012545 for ietf-provreg-outgoing; Fri, 3 Apr 2009 00:40:19 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.130]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n32MeGoO008492 for ; Fri, 3 Apr 2009 00:40:18 +0200 (MEST)
Received: from clam.local (host671420093250.direcway.com [67.142.250.93] (may be forged)) by abenaki.wabanaki.net (8.14.2/8.14.2) with ESMTP id n32M32Dk008700; Thu, 2 Apr 2009 17:03:05 -0500 (EST) (envelope-from [email-masked])
Message-ID: <[email-masked]>
Date: Thu, 02 Apr 2009 18:40:02 -0400
From: Eric Brunner-Williams
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: =?windows-1252?Q?Patrik_F=E4ltstr=F6m?=
CC: James Gould , "Hollenbeck, Scott" , [email-masked], EPP Provreg
Subject: Re: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

> Not fun, but there are tons of similar situations (regarding
> validation of attribute values) that also lack documentation (and lack
> of specification in the epp spec), so "to make things work", there is
> a lot of "trial and error" in the actual algorithm implemented on top
> of the epp protocol.

Yup. So the baggage that (modernly) goes with "standards track" and the
specification experience, and the contractual regime which existed when
we started are at odds, and the awkwardness isn't diminished, in my
opinion, by the present changes to the contractual regime.

If we were specifying something as generic as a provisioning protocol
for arbitrary registries, rather than the past, or currently
contemplated ICANN contracting gTLDs, augmented by some ccTLDs, to which
those special cases would tastefully decorate with their special
extensions, then the (modern) standards track requirements wouldn't seem
so otherworldly.

I'll send implementation comments separately, eventually. Remind me if I
haven't by Stockholm.

Eric

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 n32IWEZp020959 for ; Thu, 2 Apr 2009 20:32:14 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n32IWESs020958 for ietf-provreg-outgoing; Thu, 2 Apr 2009 20:32:14 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n32IWCF7005418 for ; Thu, 2 Apr 2009 20:32:13 +0200 (MEST)
X-Files: PGP.sig : 186
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-6.cisco.com with ESMTP; 02 Apr 2009 18:32:04 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n32IW4At022202; Thu, 2 Apr 2009 20:32:04 +0200
Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n32IW4eF014044; Thu, 2 Apr 2009 18:32:04 GMT
Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 20:32:04 +0200
Received: from 94.191.163.252.bredband.tre.se ([10.61.97.6]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 20:32:02 +0200
Cc: "Hollenbeck, Scott" , , EPP Provreg
Message-Id: <[email-masked]>
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=
To: James Gould
In-Reply-To:
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-34-544391567"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs
Date: Thu, 2 Apr 2009 20:31:52 +0200
References:
X-Pgp-Agent: GPGMail d55 (v55, Leopard)
X-Mailer: Apple Mail (2.930.3)
X-OriginalArrivalTime: 02 Apr 2009 18:32:03.0288 (UTC) FILETIME=[516C4580:01C9B3C1]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4702; t=1238697124; x=1239561124; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[email-masked]; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20
|Subject:=20Re=3A=20[ietf-provreg]=20RE=3A=20Standards=20Tr ack=20Advancement=20Request=20for=20EPP=20RFCs |Sender:=20; bh=mEPpS8aCBhpQon1UJn870aob5UBF1ZfZNhzCFtVl8lE=; b=wROwQEaJrMLDwUNm6lezacoW6OkY11k6+QxceO9jTLWAxRBxlRU2lF7anJ iOKXhU1/QxAS+Gm0FuuHwmOHZPwik/xn0XRxHpSmc8CBYMeKVoFKD7r4VyrQ NKi1h0V/o4;
Authentication-Results: ams-dkim-2; header.From=[email-masked]; dkim=pass ( sig from cisco.com/amsdkim2001 verified; );
Sender: [email-masked]
Precedence: bulk

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-34-544391567
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable

On 2 apr 2009, at 19.30, James Gould wrote:

> JG =96 You are referring to internal hosts that are subordinate to a =20=

> domain in
> the case of the host ns.foo.se and domain foo.se, but how do you =20
> handle
> external hosts like ns.bar.net that is not subordinate to any domain =20=

> in .se?
> In our Registries, child hosts of a domain (ns.foo.se for foo.se) =20
> are also
> transferred along with the domain and the sponsoring client must be =20=

> the
> same. Since there is no parent domain for an external host =20
> (ns.bar.net in
> .se) you can=92t include the same type of validation. The =20
> specification says
> that =93changing an external host object that has associations with =20=

> objects
> that are sponsored by a different client should result in a EPP =20
> error code
> 2305=94, which means that if one client references an external host =20=

> sponsored
> by a different client, that the host can not be changed. Does this =20=

> apply to
> any change or just a change like changing the host name? This =20
> statement
> means for a Registry with many domains and external hosts, that =20
> there is
> much more work required by the sponsoring client to create a new =20
> host and
> update all of their domains that link to the host to reference the =20
> new host.
> Implementing this represents a substantial change to the way that =20
> Registrars
> manage external hosts, at least in our Registries, unless the first =20=

> approach
> is implemented where each client has it=92s own list of external =20
> hosts. The
> .name Registry implements the first option.

.SE transfer the host object together with the domain it belongs to. =20
host objects outside of .se have no sponsoring clients.

That is the explanation (and there are no more words), and when =20
reverse engineering what has actually been implemented, I found that =20
the best I can do is to always try to create the host object when I =20
have some operation to do on a domain object, and more or less ignore =20=

the error code...

Not fun, but there are tons of similar situations (regarding =20
validation of attribute values) that also lack documentation (and lack =20=

of specification in the epp spec), so "to make things work", there is =20=

a lot of "trial and error" in the actual algorithm implemented on top =20=

of the epp protocol.

>> So what I call "cloning" is then something the gaining registrar have
>> to do manually? Do you separate those changes of holder from a
>> "normal" change of holder, i.e. restart the payment cycle etc? Do you
>> keep track of the now two contact records be the "same" contact be
>> represented by two records? You as registry that is.
>
> JG - Yes, if the Registrar wants to update the contact information =20=

> linked
> by the domain than they have to either request a transfer of the =20
> contacts or
> manually create or reuse an existing contact record to link to the =20
> domain.
> Updating the transferred domain to reference new contact data is =20
> handled in
> the same way as any domain update. There is no side effects =20
> associated with
> billing, since the billable action was transferring the domain and the
> contact information can be changed at any time.

In .SE there is a difference. Changing the holder do have legal =20
impact, and the registry require paperwork etc. So changing that =20
attribute value is a "special" operation. What is interesting though =20
is that .SE is themselves as registry cloning the holder and updates =20
the holderid when a transfer happens. That implies that if you track =20
domains in .SE, you will see a change of holder(-id) when a transfer =20
happens even though there was no change in holder. Yes, that implies =20
creation of many many many contact objects over time. Contacts have to =20=

be deleted manually by the registrar.

I do not like it, but that is how they have implemented contacts.

Patrik

--Apple-Mail-34-544391567
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iD8DBQFJ1QSYvHlR2X0luNwRArRdAJ9e97wnc8FRUsQcGyRWEHvwQdG9AgCcDo1n
F0ZrDDZ/Hwrtc1FYSVVm+oU=
=B9tp
-----END PGP SIGNATURE-----

--Apple-Mail-34-544391567--

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 n32HUOKx001849 for ; Thu, 2 Apr 2009 19:30:24 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n32HUOrp010487 for ietf-provreg-outgoing; Thu, 2 Apr 2009 19:30:24 +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 n32HUMti017661 for ; Thu, 2 Apr 2009 19:30:23 +0200 (MEST)
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 n32HMOSd032415; Thu, 2 Apr 2009 13:22:24 -0400
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, 2 Apr 2009 13:30:16 -0400
Received: from 10.131.29.236 ([10.131.29.236]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Thu, 2 Apr 2009 17:30:15 +0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Thu, 02 Apr 2009 13:30:13 -0400
Subject: Re: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs
From: James Gould
To: Patrik =?ISO-8859-1?B?RuRsdHN0cvZt?=
CC: "Hollenbeck, Scott" , , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs
Thread-Index: AcmztN0KiVITr3NRThmXqQZxl9RQhgAA9Dgn
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3321523814_11617021"
X-OriginalArrivalTime: 02 Apr 2009 17:30:16.0536 (UTC) FILETIME=[B006CD80:01C9B3B8]
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_3321523814_11617021
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Patrik,

My responses are below, prefixed with "JG - ".

--=20

JG=20

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

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

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

> From: Patrik F=E4ltstr=F6m
> Date: Thu, 2 Apr 2009 12:55:08 -0400
> To: James Gould
> Cc: "Hollenbeck, Scott" , ,
> EPP Provreg
> Subject: Re: [ietf-provreg] RE: Standards Track Advancement Request for E=
PP
> RFCs
>=20
> On 2 apr 2009, at 15.44, James Gould wrote:
>=20
>>> Host name changes can have an impact on associated objects that
>>> refer to the
>>> host object. A host name change SHOULD NOT require additional
>>> updates of
>>> associated objects to preserve existing associations, with one
>>> exception:
>>> changing an external host object that has associations with objects
>>> that are
>>> sponsored by a different client. Attempts to update such hosts
>>> directly MUST
>>> fail with EPP error code 2305. The change can be provisioned by
>>> creating a new
>>> external host with a new name and needed new attributes and
>>> subsequently
>>> updating the other objects sponsored by the client.
>>=20
>> Have any Registries implemented to this? We=B9ve implemented external
>> hosts
>> in two different ways:
>>=20
>> 1. External hosts per Registrar, where an association from domains to
>> external hosts of another client (Registrar) is not allowed.
>> 2. External hosts per Registry, where updates are allowed to be made
>> by the
>> sponsoring Registrar independent of the associations to the domains.
>=20
> In .SE the host object is subordinate the domain object, and therefore
> MUST have the same sponsoring client as the domain object. A host
> object is transferred with the domain object, and is because of that
> not transferMy resprable.
>=20

JG =AD You are referring to internal hosts that are subordinate to a domain i=
n
the case of the host ns.foo.se and domain foo.se, but how do you handle
external hosts like ns.bar.net that is not subordinate to any domain in .se=
?
In our Registries, child hosts of a domain (ns.foo.se for foo.se) are also
transferred along with the domain and the sponsoring client must be the
same. Since there is no parent domain for an external host (ns.bar.net in
.se) you can=B9t include the same type of validation. The specification says
that =B3changing an external host object that has associations with objects
that are sponsored by a different client should result in a EPP error code
2305=B2, which means that if one client references an external host sponsored
by a different client, that the host can not be changed. Does this apply t=
o
any change or just a change like changing the host name? This statement
means for a Registry with many domains and external hosts, that there is
much more work required by the sponsoring client to create a new host and
update all of their domains that link to the host to reference the new host=
.
Implementing this represents a substantial change to the way that Registrar=
s
manage external hosts, at least in our Registries, unless the first approac=
h
is implemented where each client has it=B9s own list of external hosts. The
.name Registry implements the first option.

>>> On the first, I see differences on how transfers of domains and
>>> "attached objects" work. Some registries require explicit transfer of
>>> contacts, which imply one (as I think) might as registrar have access
>>> to the domain object, but not contact. Other registries do clone the
>>> contact object when a domain is transferred, and the clone get a new
>>> contact-id (which imply the number of contact objects in the database
>>> increase, and the contact-id of holder change in the domain when the
>>> transfer happens.
>>=20
>> JG - We've treated contacts as first class objects, where a domain
>> transfer
>> doesn't do anything with the contacts. If the gaining Registrar
>> needs to
>> make updates to the contact records, new contacts can be assigned
>> after the
>> transfer or the Registrar can request the transfer of the contacts.
>=20
> So what I call "cloning" is then something the gaining registrar have
> to do manually? Do you separate those changes of holder from a
> "normal" change of holder, i.e. restart the payment cycle etc? Do you
> keep track of the now two contact records be the "same" contact be
> represented by two records? You as registry that is.
>=20

JG - Yes, if the Registrar wants to update the contact information linked
by the domain than they have to either request a transfer of the contacts o=
r
manually create or reuse an existing contact record to link to the domain.
Updating the transferred domain to reference new contact data is handled in
the same way as any domain update. There is no side effects associated wit=
h
billing, since the billable action was transferring the domain and the
contact information can be changed at any time.

>>> Maybe some clarification about "contact id" is needed?
>>>=20
>>> On the second, I look specifically at the DNSSEC extension, RFC4310,
>>> where the update command is inconsistent. This is something that
>>> programmers more than myself has missed, and that required some extra
>>> hours of debugging.
>>>=20
>>> a)
>>>=20
>>>> The element is used to add DS information to an
>>>> existing set. The element MUST contain one or more
>>>> elements as described in Section 3.1.2.
>>>=20
>>> b)
>>>=20
>>>> The element contains one or more
>>>> elements that are used to remove DS data from a delegation. The
>>>> element MUST contain a key tag value as described in
>>>> section 5.1.1 of RFC 4034 [6]. Removing all DS information can
>>>> remove the ability of the parent to secure the delegation to the
>>>> child zone.
>>>=20
>>> Note that the format inside the and is
>>> different. The rem element "directly" include the keytag element
>>> while
>>> the add element include dsData (that in turn include the keytag).
>>>=20
>>> Why is there not a dsData wrapper around the keytag element for the
>>> rem command?
>>=20
>> JG - Since we're discussing RFC 4310, I have to bring up the past
>> thread on
>> the inability to use a combination of , , and
>> in a single domain update since updateType is defined
>> as a
>> choice instead of a sequence with minOccurs=3D"0" for each element.
>=20
> True, that should be clarified as well. .SE changed and do the rem
> first, and then the add. That should be the explicit order to do the
> updates in epp I think.
>=20
> Patrik
>=20

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

Re: [ietf-provreg] RE: Standards Track Advancement Request for EPP R=
FCs

Patrik,

My responses are below, prefixed with "JG - ".

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

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

> From: Patrik Fältström <[email-masked]>

> Date: Thu, 2 Apr 2009 12:55:08 -0400

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

> Cc: "Hollenbeck, Scott" <[email-masked]>, <Chri=
[email-masked]>,

> EPP Provreg <[email-masked]<=
/a>>

> Subject: Re: [ietf-provreg] RE: Standards Track Advancement Request fo=
r EPP

> RFCs

> On 2 apr 2009, at 15.44, James Gould wrote:

>>> Host name changes can have an imp=
act on associated objects that

>>> refer to the

>>> host object. A host name change SHOULD NOT require additional =

>>> updates of

>>> associated objects to preserve existing associations, with one=

>>> exception:

>>> changing an external host object that has associations with ob=
jects

>>> that are

>>> sponsored by a different client. Attempts to update such hosts=

>>> directly MUST

>>> fail with EPP error code 2305. The change can be provisioned b=
y

>>> creating a new

>>> external host with a new name and needed new attributes and &n=
bsp;

>>> subsequently

>>> updating the other objects sponsored by the client.

>> Have any Registries implemented to this?  We’ve impleme=
nted external

>> hosts

>> in two different ways:

>> 1. External hosts per Registrar, where an association from domains=
to

>> external hosts of another client (Registrar) is not allowed.

>> 2. External hosts per Registry, where updates are allowed to be ma=
de

>> by the

>> sponsoring Registrar independent of the associations to the domain=
s.

> In .SE the host object is subordinate the domain object, and therefore=

> MUST have the same sponsoring client as the domain object. A host &nbs=
p;

> object is transferred with the domain object, and is because of that &=
nbsp;

> not transferMy resprable.

JG – You are referring to internal hosts that a=
re subordinate to a domain in the case of the host ns.foo.se and domain foo.=
se, but how do you handle external hosts like ns.bar.net that is not subordi=
nate to any domain in .se?  In our Registries, child hosts of a domain =
(ns.foo.se for foo.se) are also transferred along with the domain and the sp=
onsoring client must be the same.  Since there is no parent domain for =
an external host (ns.bar.net in .se) you can’t include the same type o=
f validation.  The specification says that “changing an external =
host object that has associations with objects that are sponsored by a diffe=
rent client should result in a EPP error code 2305”, which means that =
if one client references an external host sponsored by a different client, t=
hat the host can not be changed.  Does this apply to any change or just=
a change like changing the host name?  This statement means for a Regi=
stry with many domains and external hosts, that there is much more work requ=
ired by the sponsoring client to create a new host and update all of their d=
omains that link to the host to reference the new host.  Implementing t=
his represents a substantial change to the way that Registrars manage extern=
al hosts, at least in our Registries, unless the first approach is implement=
ed where each client has it’s own list of external hosts.  The .n=
ame Registry implements the first option.

>>> On the first, I see differences on how t=
ransfers of domains and

>>> "attached objects" work. Some registries require exp=
licit transfer of

>>> contacts, which imply one (as I think) might as registrar have=
access

>>> to the domain object, but not contact. Other registries do clo=
ne the

>>> contact object when a domain is transferred, and the clone get=
a new

>>> contact-id (which imply the number of contact objects in the d=
atabase

>>> increase, and the contact-id of holder change in the domain wh=
en the

>>> transfer happens.

>> JG - We've treated contacts as first class objects, where a domain=

>> transfer

>> doesn't do anything with the contacts.  If the gaining Regist=
rar

>> needs to

>> make updates to the contact records, new contacts can be assigned =

>> after the

>> transfer or the Registrar can request the transfer of the contacts=
.

> So what I call "cloning" is then something the gaining regis=
trar have

> to do manually? Do you separate those changes of holder from a  <=
BR>
> "normal" change of holder, i.e. restart the payment cycle et=
c? Do you

> keep track of the now two contact records be the "same" cont=
act be

> represented by two records? You as registry that is.

JG -  Yes, if the Registrar wants to upda=
te the contact information linked by the domain than they have to either req=
uest a transfer of the contacts or manually create or reuse an existing cont=
act record to link to the domain.  Updating the transferred domain to r=
eference new contact data is handled in the same way as any domain update. &=
nbsp;There is no side effects associated with billing, since the billable ac=
tion was transferring the domain and the contact information can be changed =
at any time.

>>> Maybe some clarification about &q=
uot;contact id" is needed?

>>> On the second, I look specifically at the DNSSEC extension, RF=
C4310,

>>> where the update command is inconsistent. This is something th=
at

>>> programmers more than myself has missed, and that required som=
e extra

>>> hours of debugging.

>>> a)

>>>> The <secDNS:add> elemen=
t is used to add DS information to an

>>>> existing set. The <secDNS:add> element MUST contain =
one or more

>>>> <secDNS: dsData> elements as described in Section 3.=
1.2.

>>> b)

>>>> The <secDNS:rem> elemen=
t contains one or more <secDNS:keyTag>

>>>> elements that are used to remove DS data from a delegation=
. The

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

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

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

>>>> child zone.

>>> Note that the format inside the <secDNS:add> and <sec=
DNS:rem> is

>>> different. The rem element "directly" include the ke=
ytag element

>>> while

>>> the add element include dsData (that in turn include the keyta=
g).

>>> Why is there not a dsData wrapper around the keytag element fo=
r the

>>> rem command?

>> JG - Since we're discussing RFC 4310, I have to bring up the past =

>> thread on

>> the inability to use a combination of <secDNS:add>, <secD=
NS:rem>, and

>> <secDNS:chg> in a single domain update since updateType is d=
efined

>> as a

>> choice instead of a sequence with minOccurs=3D"0" for each=
element.

> True, that should be clarified as well. .SE changed and do the rem &nb=
sp;

> first, and then the add. That should be the explicit order to do the &=
nbsp;

> updates in epp I think.

>     Patrik

--B_3321523814_11617021--

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 n32H30Re000009 for ; Thu, 2 Apr 2009 19:03:00 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n32H30tk011307 for ietf-provreg-outgoing; Thu, 2 Apr 2009 19:03:00 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n32H2xGF016721 for ; Thu, 2 Apr 2009 19:03:00 +0200 (MEST)
X-Files: PGP.sig : 186
X-IronPort-AV: E=Sophos;i="4.39,315,1235952000"; d="sig'?scan'208";a="149657371"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-3.cisco.com with ESMTP; 02 Apr 2009 17:02:51 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n32H2pMO024412; Thu, 2 Apr 2009 19:02:51 +0200
Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n32H2pM3026350; Thu, 2 Apr 2009 17:02:51 GMT
Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 19:02:51 +0200
Received: from 94.191.163.252.bredband.tre.se ([10.61.97.6]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 19:02:50 +0200
Cc:
Message-Id: <[email-masked]>
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=
To: Edward Lewis
In-Reply-To:
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-12-538658048"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: RFC 4310 RE: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs
Date: Thu, 2 Apr 2009 18:56:19 +0200
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
X-Pgp-Agent: GPGMail d55 (v55, Leopard)
X-Mailer: Apple Mail (2.930.3)
X-OriginalArrivalTime: 02 Apr 2009 17:02:50.0629 (UTC) FILETIME=[DAFD5350:01C9B3B4]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1059; t=1238691771; x=1239555771; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[email-masked]; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20
|Subject:=20Re=3A=20RFC=204310=20RE=3A=20[ietf-provreg]=20R E=3A=20Standards=20Track=20Advancement=20Request=20for=20EPP =20RFCs |Sender:=20; bh=euIeQP3wXV+ugRgaNHi9yqlBkH8UV+/5d0aXStP6Si0=; b=X25EKpjAS/p0J4oJL6M27rvPHLesgHUzxxODZqTTMH9BzHDFIbG/Rlpjaz WB2eDTXNy/RY5kSiVqnCISZsAIccbChvG21AQmnrlgwNDaXhM1aDCgnxnzWW AvOdZH/26n;
Authentication-Results: ams-dkim-1; header.From=[email-masked]; dkim=pass ( sig from cisco.com/amsdkim1002 verified; );
Sender: [email-masked]
Precedence: bulk

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-12-538658048
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

On 2 apr 2009, at 16.27, Edward Lewis wrote:

> FWIW, we found that RFC 4310 in it's current state to be quirky but
> workable.
>
> I would prefer that we not redefine what's in 4310, although if we
> want to improve on it we create a new extension (which has less
> quirks).

I agree with this.

The only thing I ask for is maybe some more words so that the reader
catches the quirks.

Patrik

--Apple-Mail-12-538658048
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iD8DBQFJ1O4zvHlR2X0luNwRAj4wAJ9MhlMgG6w0Wa8UUftZzY+3BlQOFQCg7PYV
rjad3ssW1jawpaJn92RvK6Y=
=+CiB
-----END PGP SIGNATURE-----

--Apple-Mail-12-538658048--

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 n32H2rTS004733 for ; Thu, 2 Apr 2009 19:02:53 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n32H2rXk008783 for ietf-provreg-outgoing; Thu, 2 Apr 2009 19:02:53 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n32H2qgP014246 for ; Thu, 2 Apr 2009 19:02:52 +0200 (MEST)
X-Files: PGP.sig : 186
X-IronPort-AV: E=Sophos;i="4.39,315,1235952000"; d="sig'?scan'208";a="165729769"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-1.cisco.com with ESMTP; 02 Apr 2009 17:02:50 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n32H2nCS003943; Thu, 2 Apr 2009 19:02:49 +0200
Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n32H2nZd026337; Thu, 2 Apr 2009 17:02:49 GMT
Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 19:02:49 +0200
Received: from 94.191.163.252.bredband.tre.se ([10.61.97.6]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 19:02:48 +0200
Cc: "Hollenbeck, Scott" , , EPP Provreg
Message-Id:
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=
To: James Gould
In-Reply-To:
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-11-538587215"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs
Date: Thu, 2 Apr 2009 18:55:08 +0200
References:
X-Pgp-Agent: GPGMail d55 (v55, Leopard)
X-Mailer: Apple Mail (2.930.3)
X-OriginalArrivalTime: 02 Apr 2009 17:02:48.0988 (UTC) FILETIME=[DA02EDC0:01C9B3B4]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4973; t=1238691769; x=1239555769; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[email-masked]; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20
|Subject:=20Re=3A=20[ietf-provreg]=20RE=3A=20Standards=20Tr ack=20Advancement=20Request=20for=20EPP=20RFCs |Sender:=20; bh=irmHBZ2/J50b5ys+Xe5jj636k8S8ULek5zLKTosRCbE=; b=X87/+Te092oX5Nx6ZMrq7utZGNPFDEu2Ymhjlp2GyozOc3w4tYixeKpRsQ CgY2dHKm3gTKoWKmFFzfyjNgu89YaJJOfde7GFqT5Ky2ZjEy728pXO3f/TF0 +D4BbSWUNs;
Authentication-Results: ams-dkim-2; header.From=[email-masked]; dkim=pass ( sig from cisco.com/amsdkim2001 verified; );
Sender: [email-masked]
Precedence: bulk

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-11-538587215
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable

On 2 apr 2009, at 15.44, James Gould wrote:

>> Host name changes can have an impact on associated objects that =20
>> refer to the
>> host object. A host name change SHOULD NOT require additional =20
>> updates of
>> associated objects to preserve existing associations, with one =20
>> exception:
>> changing an external host object that has associations with objects =20=

>> that are
>> sponsored by a different client. Attempts to update such hosts =20
>> directly MUST
>> fail with EPP error code 2305. The change can be provisioned by =20
>> creating a new
>> external host with a new name and needed new attributes and =20
>> subsequently
>> updating the other objects sponsored by the client.
>
> Have any Registries implemented to this? We=92ve implemented external =
=20
> hosts
> in two different ways:
>
> 1. External hosts per Registrar, where an association from domains to
> external hosts of another client (Registrar) is not allowed.
> 2. External hosts per Registry, where updates are allowed to be made =20=

> by the
> sponsoring Registrar independent of the associations to the domains.

In .SE the host object is subordinate the domain object, and therefore =20=

MUST have the same sponsoring client as the domain object. A host =20
object is transferred with the domain object, and is because of that =20
not transferrable.

>> On the first, I see differences on how transfers of domains and
>> "attached objects" work. Some registries require explicit transfer of
>> contacts, which imply one (as I think) might as registrar have access
>> to the domain object, but not contact. Other registries do clone the
>> contact object when a domain is transferred, and the clone get a new
>> contact-id (which imply the number of contact objects in the database
>> increase, and the contact-id of holder change in the domain when the
>> transfer happens.
>
> JG - We've treated contacts as first class objects, where a domain =20
> transfer
> doesn't do anything with the contacts. If the gaining Registrar =20
> needs to
> make updates to the contact records, new contacts can be assigned =20
> after the
> transfer or the Registrar can request the transfer of the contacts.

So what I call "cloning" is then something the gaining registrar have =20=

to do manually? Do you separate those changes of holder from a =20
"normal" change of holder, i.e. restart the payment cycle etc? Do you =20=

keep track of the now two contact records be the "same" contact be =20
represented by two records? You as registry that is.

>> Maybe some clarification about "contact id" is needed?
>>
>> On the second, I look specifically at the DNSSEC extension, RFC4310,
>> where the update command is inconsistent. This is something that
>> programmers more than myself has missed, and that required some extra
>> hours of debugging.
>>
>> a)
>>
>>> The element is used to add DS information to an
>>> existing set. The element MUST contain one or more
>>> elements as described in Section 3.1.2.
>>
>> b)
>>
>>> The element contains one or more
>>> elements that are used to remove DS data from a delegation. The
>>> element MUST contain a key tag value as described in
>>> section 5.1.1 of RFC 4034 [6]. Removing all DS information can
>>> remove the ability of the parent to secure the delegation to the
>>> child zone.
>>
>> Note that the format inside the and is
>> different. The rem element "directly" include the keytag element =20
>> while
>> the add element include dsData (that in turn include the keytag).
>>
>> Why is there not a dsData wrapper around the keytag element for the
>> rem command?
>
> JG - Since we're discussing RFC 4310, I have to bring up the past =20
> thread on
> the inability to use a combination of , , and
> in a single domain update since updateType is defined =20
> as a
> choice instead of a sequence with minOccurs=3D"0" for each element.

True, that should be clarified as well. .SE changed and do the rem =20
first, and then the add. That should be the explicit order to do the =20
updates in epp I think.

Patrik

--Apple-Mail-11-538587215
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iD8DBQFJ1O3svHlR2X0luNwRAs+6AKC4Q0J4GCNT/3g1x8Bj6rHdf1gRWACgzavU
atYXMHlI7MiLHYUDpdpYyJc=
=wdiy
-----END PGP SIGNATURE-----

--Apple-Mail-11-538587215--

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 n32ERSk1017837 for ; Thu, 2 Apr 2009 16:27:28 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n32ERS6Z010363 for ietf-provreg-outgoing; Thu, 2 Apr 2009 16:27:28 +0200 (MEST)
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 n32EROr4020324 for ; Thu, 2 Apr 2009 16:27:27 +0200 (MEST)
Received: from [10.31.200.209] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n32ERKtB015592; Thu, 2 Apr 2009 10:27:20 -0400 (EDT) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Thu, 2 Apr 2009 10:27:17 -0400
To:
From: Edward Lewis
Subject: RFC 4310 RE: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs
Cc: [email-masked]
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n32ERSr4026702
Sender: [email-masked]
Precedence: bulk

FWIW, we found that RFC 4310 in it's current state to be quirky but workable.

I would prefer that we not redefine what's in
4310, although if we want to improve on it we
create a new extension (which has less quirks).

At 9:36 -0400 4/2/09, Hollenbeck, Scott wrote:
>Patrik,
>
>I'm open to clarifying protocol text and I'll
>work with Chris to make sure that any proposed
>changes stay in scope. Sending specific text
>changes/additions would be appreciated.
>
>I'm not planning to touch 4310. I've heard
>enough about that spec from different people
>with operational experience to make me think
>that it needs a respin at Proposed with either
>protocol updates or a complete re-write. I
>don't have time to take on that work, so I've
>offered to give up the editing pen to others
>that have asked about it privately. Consider
>this a public offer.
>
>-Scott-
>
>> -----Original Message-----
>> From: Patrik Fältström [mailto:[email-masked]]
>> Sent: Thursday, April 02, 2009 8:49 AM
>> To: Hollenbeck, Scott
>> Cc: [email-masked]; [email-masked]
>> Subject: Re: [ietf-provreg] RE: Standards Track Advancement
>> Request for EPP RFCs
>>
>> Hmm....in this time period you talk about, I have implemented
>> epp from the beginning -- twice -- and got quite some
>> experience. There are a few things that would be good to
>> clarify, although they to some degree have to do with the
>> database management and structure and not so much the actual protocol.
>>
>> Then small things that could have been better I think, but I
>> guess everyone have implemented this already, so to make the
>> changes might be wrong at this point (and not necessary).
>>
>> On the first, I see differences on how transfers of domains
>> and "attached objects" work. Some registries require explicit
>> transfer of contacts, which imply one (as I think) might as
>> registrar have access to the domain object, but not contact.
>> Other registries do clone the contact object when a domain is
>> transferred, and the clone get a new contact-id (which imply
>> the number of contact objects in the database increase, and
>> the contact-id of holder change in the domain when the
>> transfer happens.
>>
>> Maybe some clarification about "contact id" is needed?
>>
>> On the second, I look specifically at the DNSSEC extension,
>> RFC4310, where the update command is inconsistent. This is
>> something that programmers more than myself has missed, and
>> that required some extra hours of debugging.
>>
>> a)
>>
>> > The element is used to add DS information to
>> an existing
>> > set. The element MUST contain one or more
>> > elements as described in Section 3.1.2.
>>
>> b)
>>
>> > The element contains one or more
>> > elements that are used to remove DS data from a delegation. The
>> > element MUST contain a key tag value as
>> described in
>> > section 5.1.1 of RFC 4034 [6]. Removing all DS information can
>> > remove the ability of the parent to secure the delegation to the
>> > child zone.
>>
>> Note that the format inside the and is
>> different. The rem element "directly" include the keytag
>> element while
>> the add element include dsData (that in turn include the keytag).
>>
>> Why is there not a dsData wrapper around the keytag element for the
>> rem command?
>>
>> c)
>>
>> .SE have added a feature in the update command, and that is that the
>> keyID in a rem update can use the specific key tag "0" that
>> imply all
>> keys are to be removed.
>>
>> Are these things that could be interesting to discuss, and if so,
>> should I send text somewhere?
>>
>> Patrik
>>
>> On 2 apr 2009, at 13.18, Hollenbeck, Scott wrote:
>>
>> > (trimming the recipients a bit)
>> >
>> > It's been 3 months since I last heard from anyone who had
>> any concerns
>> > with moving forward, so I'm going to get moving. I have
>> copies of the
>> > XML source files for the current RFCs to use as a basis for new I-
>> > Ds. I
>> > intend to update references in RFCs 4930-4934 as needed. I will add
>> > text to 4934 to better describe the TLS usage profile as noted by
>> > Chris.
>> >
>> > -Scott-
>> >
>> >> -----Original Message-----
>> >> From: [email-masked] [mailto:[email-masked]]
>> >> Sent: Tuesday, December 16, 2008 12:08 AM
>> >> To: Hollenbeck, Scott; [email-masked]
>> >> Cc: [email-masked]; [email-masked]
>> >> Subject: RE: Standards Track Advancement Request for EPP RFCs
>> >>
>> >> Two questions I missed:
>> >>
>> >> --On October 17, 2008 8:28:31 -0400 "Hollenbeck, Scott"
>> >> wrote:
>> >>> 4291: is its status a show-stopper for advancement? I'd
>> >> like to have
>> >>> that question answered before I invest a lot of time in making any
>> >>> document updates to address the TLS topics you noted.
>> >>
>> >> This is a case for RFC 3967, IMHO. While I can't predict how
>> >> the rest of the IETF will behave on this point, the only
>> >> alternative would be to rip
>> >> IPv6 support out of the base spec into a separate extension
>> >> that doesn't advance on the standards track. I would find it
>> >> quite surprising if the IETF/IESG choose that alternative to RFC
>> >> 3967.
>> >>
>> >>> Can you point me to another specification that includes a
>> TLS usage
>> >>> profile that addresses the features you described? I'd
>> >> like to see an
>> >>> example that has recently passed muster with the IESG.
>> >>
>> >> The most recent is:
>> >>
>> >>
>> >> - Chris
>> >>
>> >>
>> >
>>
>>

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

Getting everything you want is easy if you don't want much.

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 n32DiPTk000263 for ; Thu, 2 Apr 2009 15:44:25 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n32DiPeO014886 for ietf-provreg-outgoing; Thu, 2 Apr 2009 15:44:25 +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 n32DiO36027567 for ; Thu, 2 Apr 2009 15:44:24 +0200 (MEST)
Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id n32DaUXd020047; Thu, 2 Apr 2009 09:36:30 -0400
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 09:44:22 -0400
Received: from 10.131.29.236 ([10.131.29.236]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Thu, 2 Apr 2009 13:44:21 +0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Thu, 02 Apr 2009 09:44:12 -0400
Subject: Re: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs
From: James Gould
To: Patrik =?ISO-8859-1?B?RuRsdHN0cvZt?= , "Hollenbeck, Scott"
CC: , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs
Thread-Index: AcmzlQAYH5JoG5ELS7Os2zJsfyxy9gABBrXd
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3321510255_10789402"
X-OriginalArrivalTime: 02 Apr 2009 13:44:22.0141 (UTC) FILETIME=[20FA42D0:01C9B399]
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_3321510255_10789402
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Patrik,

I provide feedback to the items that you bring up based on my experience of
building Registries below.

One additional item that I noticed with a recent re-review of RFC 4932 (EPP
Host Mapping) is the following verbiage:
=20
> Host name changes can have an impact on associated objects that refer to =
the
> host object. A host name change SHOULD NOT require additional updates of
> associated objects to preserve existing associations, with one exception:
> changing an external host object that has associations with objects that =
are
> sponsored by a different client. Attempts to update such hosts directly M=
UST
> fail with EPP error code 2305. The change can be provisioned by creating =
a new
> external host with a new name and needed new attributes and subsequently
> updating the other objects sponsored by the client.

Have any Registries implemented to this? We=B9ve implemented external hosts
in two different ways:

1. External hosts per Registrar, where an association from domains to
external hosts of another client (Registrar) is not allowed.
2. External hosts per Registry, where updates are allowed to be made by the
sponsoring Registrar independent of the associations to the domains.

--=20

JG=20

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

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

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

> From: Patrik F=E4ltstr=F6m
> Date: Thu, 2 Apr 2009 08:49:06 -0400
> To: "Hollenbeck, Scott"
> Cc: , EPP Provreg
> Subject: Re: [ietf-provreg] RE: Standards Track Advancement Request for E=
PP
> RFCs
>=20
> Hmm....in this time period you talk about, I have implemented epp from
> the beginning -- twice -- and got quite some experience. There are a
> few things that would be good to clarify, although they to some degree
> have to do with the database management and structure and not so much
> the actual protocol.
>=20
> Then small things that could have been better I think, but I guess
> everyone have implemented this already, so to make the changes might
> be wrong at this point (and not necessary).
>=20
> On the first, I see differences on how transfers of domains and
> "attached objects" work. Some registries require explicit transfer of
> contacts, which imply one (as I think) might as registrar have access
> to the domain object, but not contact. Other registries do clone the
> contact object when a domain is transferred, and the clone get a new
> contact-id (which imply the number of contact objects in the database
> increase, and the contact-id of holder change in the domain when the
> transfer happens.

JG - We've treated contacts as first class objects, where a domain transfer
doesn't do anything with the contacts. If the gaining Registrar needs to
make updates to the contact records, new contacts can be assigned after the
transfer or the Registrar can request the transfer of the contacts.

>=20
> Maybe some clarification about "contact id" is needed?
>=20
> On the second, I look specifically at the DNSSEC extension, RFC4310,
> where the update command is inconsistent. This is something that
> programmers more than myself has missed, and that required some extra
> hours of debugging.
>=20
> a)
>=20
>> The element is used to add DS information to an
>> existing set. The element MUST contain one or more
>> elements as described in Section 3.1.2.
>=20
> b)
>=20
>> The element contains one or more
>> elements that are used to remove DS data from a delegation. The
>> element MUST contain a key tag value as described in
>> section 5.1.1 of RFC 4034 [6]. Removing all DS information can
>> remove the ability of the parent to secure the delegation to the
>> child zone.
>=20
> Note that the format inside the and is
> different. The rem element "directly" include the keytag element while
> the add element include dsData (that in turn include the keytag).
>=20
> Why is there not a dsData wrapper around the keytag element for the
> rem command?

JG - Since we're discussing RFC 4310, I have to bring up the past thread on
the inability to use a combination of , , and
in a single domain update since updateType is defined as a
choice instead of a sequence with minOccurs=3D"0" for each element.

>=20
> c)
>=20
> .SE have added a feature in the update command, and that is that the
> keyID in a rem update can use the specific key tag "0" that imply all
> keys are to be removed.
>=20
> Are these things that could be interesting to discuss, and if so,
> should I send text somewhere?
>=20
> Patrik
>=20
> On 2 apr 2009, at 13.18, Hollenbeck, Scott wrote:
>=20
>> (trimming the recipients a bit)
>>=20
>> It's been 3 months since I last heard from anyone who had any concerns
>> with moving forward, so I'm going to get moving. I have copies of the
>> XML source files for the current RFCs to use as a basis for new I-
>> Ds. I
>> intend to update references in RFCs 4930-4934 as needed. I will add
>> text to 4934 to better describe the TLS usage profile as noted by
>> Chris.
>>=20
>> -Scott-
>>=20
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]]
>>> Sent: Tuesday, December 16, 2008 12:08 AM
>>> To: Hollenbeck, Scott; [email-masked]
>>> Cc: [email-masked]; [email-masked]
>>> Subject: RE: Standards Track Advancement Request for EPP RFCs
>>>=20
>>> Two questions I missed:
>>>=20
>>> --On October 17, 2008 8:28:31 -0400 "Hollenbeck, Scott"
>>> wrote:
>>>> 4291: is its status a show-stopper for advancement? I'd
>>> like to have
>>>> that question answered before I invest a lot of time in making any
>>>> document updates to address the TLS topics you noted.
>>>=20
>>> This is a case for RFC 3967, IMHO. While I can't predict how
>>> the rest of the IETF will behave on this point, the only
>>> alternative would be to rip
>>> IPv6 support out of the base spec into a separate extension
>>> that doesn't advance on the standards track. I would find it
>>> quite surprising if the IETF/IESG choose that alternative to RFC
>>> 3967.
>>>=20
>>>> Can you point me to another specification that includes a TLS usage
>>>> profile that addresses the features you described? I'd
>>> like to see an
>>>> example that has recently passed muster with the IESG.
>>>=20
>>> The most recent is:
>>>
>>>=20
>>> - Chris
>>>=20
>>>=20
>>=20
>=20

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

Re: [ietf-provreg] RE: Standards Track Advancement Request for EPP R=
FCs

Patrik,

I provide feedback to the items that you bring up based on my experience of=
building Registries below.

One additional item that I noticed with a recent re-review of RFC 4932 (EPP=
Host Mapping) is the following verbiage:

<=
SPAN STYLE=3D'font-size:11pt'>Host name changes can have an impact on associat=
ed objects that refer to the host object. A host name change SHOULD NOT requ=
ire additional updates of associated objects to preserve existing associatio=
ns, with one exception: changing an external host object that has associa=
tions with objects that are sponsored by a different client. Attempts to upd=
ate such hosts directly MUST fail with EPP error code 2305. The change can b=
e provisioned by creating a new external host with a new name and needed new=
attributes and subsequently updating the other objects sponsored by the cli=
ent.

Have any Registries implemented to this?  We’ve implemented exte=
rnal hosts in two different ways:

External hosts per Registrar, where an association f=
rom domains to external hosts of another client (Registrar) is not allowed.

External hosts per Registry, where updates are allowed t=
o be made by the sponsoring Registrar independent of the associations to the=
domains.

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

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

> From: Patrik Fältström <[email-masked]>

> Date: Thu, 2 Apr 2009 08:49:06 -0400

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

> Cc: <[email-masked]>, E=
PP Provreg <[email-masked]>=

> Subject: Re: [ietf-provreg] RE: Standards Track Advancement Request fo=
r EPP

> RFCs

> Hmm....in this time period you talk about, I have implemented epp from=

> the beginning -- twice -- and got quite some experience. There are a &=
nbsp;

> few things that would be good to clarify, although they to some degree=

> have to do with the database management and structure and not so much =

> the actual protocol.

> Then small things that could have been better I think, but I guess &nb=
sp;

> everyone have implemented this already, so to make the changes might &=
nbsp;

> be wrong at this point (and not necessary).

> On the first, I see differences on how transfers of domains and  =

> "attached objects" work. Some registries require explicit tr=
ansfer of

> contacts, which imply one (as I think) might as registrar have access =

> to the domain object, but not contact. Other registries do clone the &=
nbsp;

> contact object when a domain is transferred, and the clone get a new &=
nbsp;

> contact-id (which imply the number of contact objects in the database =

> increase, and the contact-id of holder change in the domain when the &=
nbsp;

> transfer happens.

JG - We've treated contacts as first class objects, where a domain transfer=
doesn't do anything with the contacts.  If the gaining Registrar needs=
to make updates to the contact records, new contacts can be assigned after =
the transfer or the Registrar can request the transfer of the contacts. &nbs=
p;

> Maybe some clarification about "contact id" is needed?

> On the second, I look specifically at the DNSSEC extension, RFC4310, &=
nbsp;

> where the update command is inconsistent. This is something that  =
;

> programmers more than myself has missed, and that required some extra =

> hours of debugging.

> a)

>> The <secDNS:add> element is use=
d to add DS information to an

>> existing set. The <secDNS:add> element MUST contain one or m=
ore

>> <secDNS: dsData> elements as described in Section 3.1.2.

> b)

>> The <secDNS:rem> element contai=
ns one or more <secDNS:keyTag>

>> elements that are used to remove DS data from a delegation. The &n=
bsp;

>> <secDNS:keyTag> element MUST contain a key tag value as desc=
ribed in

>> section 5.1.1 of RFC 4034 [6]. Removing all DS information can &nb=
sp;

>> remove the ability of the parent to secure the delegation to the &=
nbsp;

>> child zone.

> Note that the format inside the <secDNS:add> and <secDNS:rem&=
gt; is

> different. The rem element "directly" include the keytag ele=
ment while

> the add element include dsData (that in turn include the keytag).

> Why is there not a dsData wrapper around the keytag element for the &n=
bsp;

> rem command?

JG - Since we're discussing RFC 4310, I have to bring up the past thread on=
the inability to use a combination of <secDNS:add>, <secDNS:rem>=
;, and <secDNS:chg> in a single domain update since updateType is defi=
ned as a choice instead of a sequence with minOccurs=3D"0" for each =
element.

> c)

> .SE have added a feature in the update command, and that is that the &=
nbsp;

> keyID in a rem update can use the specific key tag "0" that =
imply all

> keys are to be removed.

> Are these things that could be interesting to discuss, and if so, &nbs=
p;

> should I send text somewhere?

>     Patrik

> On 2 apr 2009, at 13.18, Hollenbeck, Scott wrote:

>> (trimming the recipients a bit)

>> It's been 3 months since I last heard from anyone who had any conc=
erns

>> with moving forward, so I'm going to get moving.  I have copi=
es of the

>> XML source files for the current RFCs to use as a basis for new I-=

>> Ds.  I

>> intend to update references in RFCs 4930-4934 as needed.  I w=
ill add

>> text to 4934 to better describe the TLS usage profile as noted by =

>> Chris.

>> -Scott-

>>> -----Original Message-----

>>> From: [email-masked] =
[mailto:[email-masked]]

>>> Sent: Tuesday, December 16, 2008 12:08 AM

>>> To: Hollenbeck, Scott; lisa@o=
safoundation.org

>>> Cc: [email-masked];=
[email-masked]

>>> Subject: RE: Standards Track Advancement Request for EPP RFCs<=
BR>

>>> Two questions I missed:

>>> --On October 17, 2008 8:28:31 -0400 "Hollenbeck, Scott&qu=
ot;

>>> <[email-masked]=
m> wrote:

>>>> 4291: is its status a show-st=
opper for advancement?  I'd

>>> like to have

>>>> that question answered before=
I invest a lot of time in making any

>>>> document updates to address the TLS topics you noted.

>>> This is a case for RFC 3967, IMHO.  While I can't predict=
how

>>> the rest of the IETF will behave on this point, the only

>>> alternative would be to rip

>>> IPv6 support out of the base spec into a separate extension
>>> that doesn't advance on the standards track.  I would fin=
d it

>>> quite surprising if the IETF/IESG choose that alternative to R=
FC

>>> 3967.

>>>> Can you point me to another s=
pecification that includes a TLS usage

>>>> profile that addresses the features you described?  I=
'd

>>> like to see an

>>>> example that has recently pas=
sed muster with the IESG.

>>> The most recent is:

>>>  <http://tools.ietf.org/html/draft-ietf-syslog-transport-tls<=
/a>>

>>> - Chris

--B_3321510255_10789402--

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 n32Daema013682 for ; Thu, 2 Apr 2009 15:36:40 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n32Daecg027812 for ietf-provreg-outgoing; Thu, 2 Apr 2009 15:36:40 +0200 (MEST)
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 n32DadNQ002145 for ; Thu, 2 Apr 2009 15:36:40 +0200 (MEST)
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 n32DRqle032610; Thu, 2 Apr 2009 09:27:52 -0400
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, 2 Apr 2009 14:36:37 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs
Date: Thu, 2 Apr 2009 09:36:39 -0400
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs
Thread-Index: AcmzkW4VLm/yLbB6RtS0Wtq3OUHcegABYitA
References: <[email-masked]> <[email-masked]> <[email-masked]>
From: "Hollenbeck, Scott"
To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?=
Cc: ,
X-OriginalArrivalTime: 02 Apr 2009 13:36:37.0811 (UTC) FILETIME=[0C372030:01C9B398]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n32DaeNQ016219
Sender: [email-masked]
Precedence: bulk

Patrik,

I'm open to clarifying protocol text and I'll work with Chris to make sure that any proposed changes stay in scope. Sending specific text changes/additions would be appreciated.

I'm not planning to touch 4310. I've heard enough about that spec from different people with operational experience to make me think that it needs a respin at Proposed with either protocol updates or a complete re-write. I don't have time to take on that work, so I've offered to give up the editing pen to others that have asked about it privately. Consider this a public offer.

-Scott-

> -----Original Message-----
> From: Patrik Fältström [mailto:[email-masked]]
> Sent: Thursday, April 02, 2009 8:49 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]; [email-masked]
> Subject: Re: [ietf-provreg] RE: Standards Track Advancement
> Request for EPP RFCs
>
> Hmm....in this time period you talk about, I have implemented
> epp from the beginning -- twice -- and got quite some
> experience. There are a few things that would be good to
> clarify, although they to some degree have to do with the
> database management and structure and not so much the actual protocol.
>
> Then small things that could have been better I think, but I
> guess everyone have implemented this already, so to make the
> changes might be wrong at this point (and not necessary).
>
> On the first, I see differences on how transfers of domains
> and "attached objects" work. Some registries require explicit
> transfer of contacts, which imply one (as I think) might as
> registrar have access to the domain object, but not contact.
> Other registries do clone the contact object when a domain is
> transferred, and the clone get a new contact-id (which imply
> the number of contact objects in the database increase, and
> the contact-id of holder change in the domain when the
> transfer happens.
>
> Maybe some clarification about "contact id" is needed?
>
> On the second, I look specifically at the DNSSEC extension,
> RFC4310, where the update command is inconsistent. This is
> something that programmers more than myself has missed, and
> that required some extra hours of debugging.
>
> a)
>
> > The element is used to add DS information to
> an existing
> > set. The element MUST contain one or more
> > elements as described in Section 3.1.2.
>
> b)
>
> > The element contains one or more
> > elements that are used to remove DS data from a delegation. The
> > element MUST contain a key tag value as
> described in
> > section 5.1.1 of RFC 4034 [6]. Removing all DS information can
> > remove the ability of the parent to secure the delegation to the
> > child zone.
>
> Note that the format inside the and is
> different. The rem element "directly" include the keytag
> element while
> the add element include dsData (that in turn include the keytag).
>
> Why is there not a dsData wrapper around the keytag element for the
> rem command?
>
> c)
>
> .SE have added a feature in the update command, and that is that the
> keyID in a rem update can use the specific key tag "0" that
> imply all
> keys are to be removed.
>
> Are these things that could be interesting to discuss, and if so,
> should I send text somewhere?
>
> Patrik
>
> On 2 apr 2009, at 13.18, Hollenbeck, Scott wrote:
>
> > (trimming the recipients a bit)
> >
> > It's been 3 months since I last heard from anyone who had
> any concerns
> > with moving forward, so I'm going to get moving. I have
> copies of the
> > XML source files for the current RFCs to use as a basis for new I-
> > Ds. I
> > intend to update references in RFCs 4930-4934 as needed. I will add
> > text to 4934 to better describe the TLS usage profile as noted by
> > Chris.
> >
> > -Scott-
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]]
> >> Sent: Tuesday, December 16, 2008 12:08 AM
> >> To: Hollenbeck, Scott; [email-masked]
> >> Cc: [email-masked]; [email-masked]
> >> Subject: RE: Standards Track Advancement Request for EPP RFCs
> >>
> >> Two questions I missed:
> >>
> >> --On October 17, 2008 8:28:31 -0400 "Hollenbeck, Scott"
> >> wrote:
> >>> 4291: is its status a show-stopper for advancement? I'd
> >> like to have
> >>> that question answered before I invest a lot of time in making any
> >>> document updates to address the TLS topics you noted.
> >>
> >> This is a case for RFC 3967, IMHO. While I can't predict how
> >> the rest of the IETF will behave on this point, the only
> >> alternative would be to rip
> >> IPv6 support out of the base spec into a separate extension
> >> that doesn't advance on the standards track. I would find it
> >> quite surprising if the IETF/IESG choose that alternative to RFC
> >> 3967.
> >>
> >>> Can you point me to another specification that includes a
> TLS usage
> >>> profile that addresses the features you described? I'd
> >> like to see an
> >>> example that has recently passed muster with the IESG.
> >>
> >> The most recent is:
> >>
> >>
> >> - Chris
> >>
> >>
> >
>
>

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 n32DXUT1023896 for ; Thu, 2 Apr 2009 15:33:31 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n32DXU76014720 for ietf-provreg-outgoing; Thu, 2 Apr 2009 15:33:30 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.130]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n32DXThp026954 for ; Thu, 2 Apr 2009 15:33:30 +0200 (MEST)
Received: from clam.local (host671420093250.direcway.com [67.142.250.93] (may be forged)) by abenaki.wabanaki.net (8.14.2/8.14.2) with ESMTP id n32CuMQq000680; Thu, 2 Apr 2009 07:56:26 -0500 (EST) (envelope-from [email-masked])
Message-ID: <[email-masked]>
Date: Thu, 02 Apr 2009 09:33:16 -0400
From: Eric Brunner-Williams
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=
CC: "Hollenbeck, Scott" , [email-masked], [email-masked]
Subject: Re: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs
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: 8bit
Sender: [email-masked]
Precedence: bulk

Patrik,

Where ever you do send it, please copy me.

Eric

Patrik Fältström wrote:
> Hmm....in this time period you talk about, I have implemented epp from
> the beginning -- twice -- and got quite some experience. There are a
> few things that would be good to clarify, although they to some degree
> have to do with the database management and structure and not so much
> the actual protocol.
>
> Then small things that could have been better I think, but I guess
> everyone have implemented this already, so to make the changes might
> be wrong at this point (and not necessary).
>
> On the first, I see differences on how transfers of domains and
> "attached objects" work. Some registries require explicit transfer of
> contacts, which imply one (as I think) might as registrar have access
> to the domain object, but not contact. Other registries do clone the
> contact object when a domain is transferred, and the clone get a new
> contact-id (which imply the number of contact objects in the database
> increase, and the contact-id of holder change in the domain when the
> transfer happens.
>
> Maybe some clarification about "contact id" is needed?
>
> On the second, I look specifically at the DNSSEC extension, RFC4310,
> where the update command is inconsistent. This is something that
> programmers more than myself has missed, and that required some extra
> hours of debugging.
>
> a)
>
>> The element is used to add DS information to an existing
>> set. The element MUST contain one or more > dsData> elements as described in Section 3.1.2.
>
> b)
>
>> The element contains one or more
>> elements that are used to remove DS data from a delegation. The
>> element MUST contain a key tag value as described in
>> section 5.1.1 of RFC 4034 [6]. Removing all DS information can remove
>> the ability of the parent to secure the delegation to the child zone.
>
> Note that the format inside the and is
> different. The rem element "directly" include the keytag element while
> the add element include dsData (that in turn include the keytag).
>
> Why is there not a dsData wrapper around the keytag element for the
> rem command?
>
> c)
>
> .SE have added a feature in the update command, and that is that the
> keyID in a rem update can use the specific key tag "0" that imply all
> keys are to be removed.
>
> Are these things that could be interesting to discuss, and if so,
> should I send text somewhere?
>
> Patrik
>
> On 2 apr 2009, at 13.18, Hollenbeck, Scott wrote:
>
>> (trimming the recipients a bit)
>>
>> It's been 3 months since I last heard from anyone who had any concerns
>> with moving forward, so I'm going to get moving. I have copies of the
>> XML source files for the current RFCs to use as a basis for new I-Ds. I
>> intend to update references in RFCs 4930-4934 as needed. I will add
>> text to 4934 to better describe the TLS usage profile as noted by Chris.
>>
>> -Scott-
>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]]
>>> Sent: Tuesday, December 16, 2008 12:08 AM
>>> To: Hollenbeck, Scott; [email-masked]
>>> Cc: [email-masked]; [email-masked]
>>> Subject: RE: Standards Track Advancement Request for EPP RFCs
>>>
>>> Two questions I missed:
>>>
>>> --On October 17, 2008 8:28:31 -0400 "Hollenbeck, Scott"
>>> wrote:
>>>> 4291: is its status a show-stopper for advancement? I'd
>>> like to have
>>>> that question answered before I invest a lot of time in making any
>>>> document updates to address the TLS topics you noted.
>>>
>>> This is a case for RFC 3967, IMHO. While I can't predict how
>>> the rest of the IETF will behave on this point, the only
>>> alternative would be to rip
>>> IPv6 support out of the base spec into a separate extension
>>> that doesn't advance on the standards track. I would find it
>>> quite surprising if the IETF/IESG choose that alternative to RFC 3967.
>>>
>>>> Can you point me to another specification that includes a TLS usage
>>>> profile that addresses the features you described? I'd
>>> like to see an
>>>> example that has recently passed muster with the IESG.
>>>
>>> The most recent is:
>>>
>>>
>>> - Chris
>>>
>>>
>>
>

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 n32Cn9Hr000034 for ; Thu, 2 Apr 2009 14:49:09 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n32Cn9tJ007034 for ietf-provreg-outgoing; Thu, 2 Apr 2009 14:49:09 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id n32Cn83j025334 for ; Thu, 2 Apr 2009 14:49:08 +0200 (MEST)
X-Files: PGP.sig : 186
X-IronPort-AV: E=Sophos;i="4.39,314,1235952000"; d="sig'?scan'208";a="37323516"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 02 Apr 2009 12:49:07 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n32Cn7Yv015477; Thu, 2 Apr 2009 14:49:07 +0200
Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n32Cn7bO024892; Thu, 2 Apr 2009 12:49:07 GMT
Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 14:49:07 +0200
Received: from wifi1-76.nic.se ([10.61.94.156]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 14:49:06 +0200
Cc: ,
Message-Id: <[email-masked]>
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=
To: "Hollenbeck, Scott"
In-Reply-To: <[email-masked]>
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-181-523824944"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs
Date: Thu, 2 Apr 2009 14:49:06 +0200
References: <[email-masked]> <[email-masked]>
X-Pgp-Agent: GPGMail d55 (v55, Leopard)
X-Mailer: Apple Mail (2.930.3)
X-OriginalArrivalTime: 02 Apr 2009 12:49:07.0227 (UTC) FILETIME=[692286B0:01C9B391]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4976; t=1238676547; x=1239540547; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[email-masked]; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20
|Subject:=20Re=3A=20[ietf-provreg]=20RE=3A=20Standards=20Tr ack=20Advancement=20Request=20for=20EPP=20RFCs |Sender:=20; bh=nArEcQbWi9CmrTRAXhOuJI3Q87/fg3nbbVr4mw/n3dw=; b=p+3ZpJk5WQSVZvQpr9ZLauu8CLjazIOyz83K3Co961rn4pnJa0ubp/GTrZ JjO/qPfDHMHN3JLN+Av1vjGtkyJg29FVfkcu0c+IsZvDIgJNXzPn9B1CheXT XubLQVe/WZ;
Authentication-Results: ams-dkim-2; header.From=[email-masked]; dkim=pass ( sig from cisco.com/amsdkim2001 verified; );
Sender: [email-masked]
Precedence: bulk

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-181-523824944
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

Hmm....in this time period you talk about, I have implemented epp from
the beginning -- twice -- and got quite some experience. There are a
few things that would be good to clarify, although they to some degree
have to do with the database management and structure and not so much
the actual protocol.

Then small things that could have been better I think, but I guess
everyone have implemented this already, so to make the changes might
be wrong at this point (and not necessary).

On the first, I see differences on how transfers of domains and
"attached objects" work. Some registries require explicit transfer of
contacts, which imply one (as I think) might as registrar have access
to the domain object, but not contact. Other registries do clone the
contact object when a domain is transferred, and the clone get a new
contact-id (which imply the number of contact objects in the database
increase, and the contact-id of holder change in the domain when the
transfer happens.

Maybe some clarification about "contact id" is needed?

On the second, I look specifically at the DNSSEC extension, RFC4310,
where the update command is inconsistent. This is something that
programmers more than myself has missed, and that required some extra
hours of debugging.

a)

> The element is used to add DS information to an
> existing set. The element MUST contain one or more
> elements as described in Section 3.1.2.

b)

> The element contains one or more
> elements that are used to remove DS data from a delegation. The
> element MUST contain a key tag value as described in
> section 5.1.1 of RFC 4034 [6]. Removing all DS information can
> remove the ability of the parent to secure the delegation to the
> child zone.

Note that the format inside the and is
different. The rem element "directly" include the keytag element while
the add element include dsData (that in turn include the keytag).

Why is there not a dsData wrapper around the keytag element for the
rem command?

c)

.SE have added a feature in the update command, and that is that the
keyID in a rem update can use the specific key tag "0" that imply all
keys are to be removed.

Are these things that could be interesting to discuss, and if so,
should I send text somewhere?

Patrik

On 2 apr 2009, at 13.18, Hollenbeck, Scott wrote:

> (trimming the recipients a bit)
>
> It's been 3 months since I last heard from anyone who had any concerns
> with moving forward, so I'm going to get moving. I have copies of the
> XML source files for the current RFCs to use as a basis for new I-
> Ds. I
> intend to update references in RFCs 4930-4934 as needed. I will add
> text to 4934 to better describe the TLS usage profile as noted by
> Chris.
>
> -Scott-
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: Tuesday, December 16, 2008 12:08 AM
>> To: Hollenbeck, Scott; [email-masked]
>> Cc: [email-masked]; [email-masked]
>> Subject: RE: Standards Track Advancement Request for EPP RFCs
>>
>> Two questions I missed:
>>
>> --On October 17, 2008 8:28:31 -0400 "Hollenbeck, Scott"
>> wrote:
>>> 4291: is its status a show-stopper for advancement? I'd
>> like to have
>>> that question answered before I invest a lot of time in making any
>>> document updates to address the TLS topics you noted.
>>
>> This is a case for RFC 3967, IMHO. While I can't predict how
>> the rest of the IETF will behave on this point, the only
>> alternative would be to rip
>> IPv6 support out of the base spec into a separate extension
>> that doesn't advance on the standards track. I would find it
>> quite surprising if the IETF/IESG choose that alternative to RFC
>> 3967.
>>
>>> Can you point me to another specification that includes a TLS usage
>>> profile that addresses the features you described? I'd
>> like to see an
>>> example that has recently passed muster with the IESG.
>>
>> The most recent is:
>>
>>
>> - Chris
>>
>>
>

--Apple-Mail-181-523824944
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iD8DBQFJ1LRCvHlR2X0luNwRAqzuAJwNEuV+Y5ZaCJZUoaoDu68RlsK9bACbBPls
7Cw6MlxVias9fYIGZENSfps=
=GACh
-----END PGP SIGNATURE-----

--Apple-Mail-181-523824944--

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 n32BIx3g021078 for ; Thu, 2 Apr 2009 13:18:59 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id n32BIx5R009860 for ietf-provreg-outgoing; Thu, 2 Apr 2009 13:18: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 n32BIwB9022093 for ; Thu, 2 Apr 2009 13:18:58 +0200 (MEST)
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 n32BB4ei013422; Thu, 2 Apr 2009 07:11:04 -0400
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, 2 Apr 2009 07:18:56 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs
Date: Thu, 2 Apr 2009 07:18:56 -0400
Message-ID: <[email-masked]>
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Standards Track Advancement Request for EPP RFCs
Thread-Index: AclfPEmLxzGQCTh9QIydcPASccvEChUR8ZUw
References: <[email-masked]>
From: "Hollenbeck, Scott"
To:
Cc:
X-OriginalArrivalTime: 02 Apr 2009 11:18:56.0154 (UTC) FILETIME=[CFE24FA0:01C9B384]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id n32BIxB9017196
Sender: [email-masked]
Precedence: bulk

(trimming the recipients a bit)

It's been 3 months since I last heard from anyone who had any concerns
with moving forward, so I'm going to get moving. I have copies of the
XML source files for the current RFCs to use as a basis for new I-Ds. I
intend to update references in RFCs 4930-4934 as needed. I will add
text to 4934 to better describe the TLS usage profile as noted by Chris.

-Scott-

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, December 16, 2008 12:08 AM
> To: Hollenbeck, Scott; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: Standards Track Advancement Request for EPP RFCs
>
> Two questions I missed:
>
> --On October 17, 2008 8:28:31 -0400 "Hollenbeck, Scott"
> wrote:
> > 4291: is its status a show-stopper for advancement? I'd
> like to have
> > that question answered before I invest a lot of time in making any
> > document updates to address the TLS topics you noted.
>
> This is a case for RFC 3967, IMHO. While I can't predict how
> the rest of the IETF will behave on this point, the only
> alternative would be to rip
> IPv6 support out of the base spec into a separate extension
> that doesn't advance on the standards track. I would find it
> quite surprising if the IETF/IESG choose that alternative to RFC 3967.
>
> > Can you point me to another specification that includes a TLS usage
> > profile that addresses the features you described? I'd
> like to see an
> > example that has recently passed muster with the IESG.
>
> The most recent is:
>
>
> - Chris
>
>