From reeneroadman@xml.yandex.ru Wed Apr 1 20:01:36 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 860123A6B92; Wed, 1 Apr 2009 20:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.672 X-Spam-Level: **** X-Spam-Status: No, score=4.672 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HOST_EQ_STATIC=1.172] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmc2ulul5VjQ; Wed, 1 Apr 2009 20:01:35 -0700 (PDT) Received: from n14z172l161.static.ctm.net (n14z172l161.static.ctm.net [202.175.172.161]) by core3.amsl.com (Postfix) with ESMTP id 90A033A685A; Wed, 1 Apr 2009 20:01:34 -0700 (PDT) Received: from [202.175.172.161] by ermak.yandex.net; Thu, 2 Apr 2009 11:02:36 +0800 From: "Wyatt Tripp" To: Subject: uw proceedings huge variety of Date: Thu, 2 Apr 2009 11:02:36 +0800 Message-ID: <01c9b382$87b81b80$a1acafca@reeneroadman> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Importance: Normal relief Happy Relax Should Happy Good Another Try Start Healthy Fix Your Sleep Health Quit crying http://groups.yahoo.com/group/stuffcoast2spyj1 proceedings From nkkbs815@naver.com Thu Apr 2 00:40:36 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8FB33A6A5F; Thu, 2 Apr 2009 00:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.05 X-Spam-Level: X-Spam-Status: No, score=-6.05 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DYNAMIC=1.144, J_CHICKENPOX_42=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN0b=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4I39LOGUGMqF; Thu, 2 Apr 2009 00:40:36 -0700 (PDT) Received: from 218-173-230-82.dynamic.hinet.net (218-173-230-82.dynamic.hinet.net [218.173.230.82]) by core3.amsl.com (Postfix) with SMTP id 593F93A6CDA; Thu, 2 Apr 2009 00:40:23 -0700 (PDT) X-Originating-IP: 65.171.164.20 by smtp.218.173.230.82; Thu, 02 Apr 2009 01:35:23 -0700 Message-ID: <316mp74073CZNEpce-bounces@ietf.org> Date: Thu, 02 Apr 2009 03:41:23 -0500 From: "Margie Ibarra" To: "Margie Ibarra" Subject: Classy, new and inexpensive watches Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Loving yourself is the first step in loving life. And what better way to do it, than by getting yourself a fine designer watch? http://www.deftdate.com/ The watch of your dreams doesn't have to be an overpriced piece of machinery. Nowadays you can get the same functionality and distinctive looks from the next best thing. Visit Diam0nd Reps and choose from hundreds of gorgeous models at less than ten percent the price of an original. http://www.deftdate.com/ With so many watches that look and work like the real thing, I guarantee you'll have a delicious time finding yours at our store! From obson@amax.com Thu Apr 2 04:09:25 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87F343A6C06 for ; Thu, 2 Apr 2009 04:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kx4+FDbqAlq3 for ; Thu, 2 Apr 2009 04:09:25 -0700 (PDT) Received: from 58-27-151-50.wateen.net (58-27-151-50.wateen.net [58.27.151.50]) by core3.amsl.com (Postfix) with SMTP id 5AF7A3A680F for ; Thu, 2 Apr 2009 04:09:22 -0700 (PDT) To: Subject: Credit card balance transfer From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090402110923.5AF7A3A680F@core3.amsl.com> Date: Thu, 2 Apr 2009 04:09:22 -0700 (PDT)
Subscribe to Men's Health Today!



Subscribe to Men's Health Today!





To your health,


David Zinczenko
Editor-in-Chief
Subscribe to Men's Health Today!
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street, Emmaus, PA 18098
From owner-ietf-provreg@cafax.se Thu Apr 2 04:34:04 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3FF23A6A43 for ; Thu, 2 Apr 2009 04:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLaXOhWHwKCs for ; Thu, 2 Apr 2009 04:34:04 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id BDE523A694F for ; Thu, 2 Apr 2009 04:34:03 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029A0E33@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Standards Track Advancement Request for EPP RFCs Thread-Index: AclfPEmLxzGQCTh9QIydcPASccvEChUR8ZUw References: <046F43A8D79C794FA4733814869CDF07026523E3@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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: Chris.Newman@Sun.COM [mailto:Chris.Newman@Sun.COM] > Sent: Tuesday, December 16, 2008 12:08 AM > To: Hollenbeck, Scott; lisa@osafoundation.org > Cc: ietf-provreg@cafax.se; iesg@ietf.org > 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 > > From owner-ietf-provreg@cafax.se Thu Apr 2 06:01:08 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B03FA28C1E7 for ; Thu, 2 Apr 2009 06:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[AWL=-3.412, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oau+P3y6jDJI for ; Thu, 2 Apr 2009 06:01:07 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 536553A6895 for ; Thu, 2 Apr 2009 06:01:06 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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: <2265CB25-98CE-4C4C-9795-682E3200BBC2@cisco.com> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Hollenbeck, Scott" In-Reply-To: <046F43A8D79C794FA4733814869CDF07029A0E33@dul1wnexmb01.vcorp.ad.vrsn.com> 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: <046F43A8D79C794FA4733814869CDF07026523E3@dul1wnexmb01.vcorp.ad.vrsn.com> <046F43A8D79C794FA4733814869CDF07029A0E33@dul1wnexmb01.vcorp.ad.vrsn.com> 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=paf@cisco.com; 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=paf@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-ietf-provreg@cafax.se 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: Chris.Newman@Sun.COM [mailto:Chris.Newman@Sun.COM] >> Sent: Tuesday, December 16, 2008 12:08 AM >> To: Hollenbeck, Scott; lisa@osafoundation.org >> Cc: ietf-provreg@cafax.se; iesg@ietf.org >> 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-- From owner-ietf-provreg@cafax.se Thu Apr 2 06:45:44 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D29728C12D for ; Thu, 2 Apr 2009 06:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSesFTpHTR-u for ; Thu, 2 Apr 2009 06:45:43 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 2C4C028C0D7 for ; Thu, 2 Apr 2009 06:45:42 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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 brunner@nic-naa.net) Message-ID: <49D4BE9C.1020800@nic-naa.net> 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" , Chris.Newman@Sun.COM, ietf-provreg@cafax.se Subject: Re: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs References: <046F43A8D79C794FA4733814869CDF07026523E3@dul1wnexmb01.vcorp.ad.vrsn.com> <046F43A8D79C794FA4733814869CDF07029A0E33@dul1wnexmb01.vcorp.ad.vrsn.com> <2265CB25-98CE-4C4C-9795-682E3200BBC2@cisco.com> In-Reply-To: <2265CB25-98CE-4C4C-9795-682E3200BBC2@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-provreg@cafax.se 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: Chris.Newman@Sun.COM [mailto:Chris.Newman@Sun.COM] >>> Sent: Tuesday, December 16, 2008 12:08 AM >>> To: Hollenbeck, Scott; lisa@osafoundation.org >>> Cc: ietf-provreg@cafax.se; iesg@ietf.org >>> 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 >>> >>> >> > From owner-ietf-provreg@cafax.se Thu Apr 2 06:48:47 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16D873A6C3A for ; Thu, 2 Apr 2009 06:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfZ43Zon0OXy for ; Thu, 2 Apr 2009 06:48:46 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 9BA5B3A6A4C for ; Thu, 2 Apr 2009 06:48:45 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029A0E3C@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <2265CB25-98CE-4C4C-9795-682E3200BBC2@cisco.com> 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: <046F43A8D79C794FA4733814869CDF07026523E3@dul1wnexmb01.vcorp.ad.vrsn.com> <046F43A8D79C794FA4733814869CDF07029A0E33@dul1wnexmb01.vcorp.ad.vrsn.com> <2265CB25-98CE-4C4C-9795-682E3200BBC2@cisco.com> 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: owner-ietf-provreg@cafax.se 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:paf@cisco.com] > Sent: Thursday, April 02, 2009 8:49 AM > To: Hollenbeck, Scott > Cc: Chris.Newman@Sun.COM; ietf-provreg@cafax.se > 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: Chris.Newman@Sun.COM [mailto:Chris.Newman@Sun.COM] > >> Sent: Tuesday, December 16, 2008 12:08 AM > >> To: Hollenbeck, Scott; lisa@osafoundation.org > >> Cc: ietf-provreg@cafax.se; iesg@ietf.org > >> 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 > >> > >> > > > > From owner-ietf-provreg@cafax.se Thu Apr 2 06:56:34 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56F8028C0D7 for ; Thu, 2 Apr 2009 06:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.307 X-Spam-Level: * X-Spam-Status: No, score=1.307 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHf9cquDMHDh for ; Thu, 2 Apr 2009 06:56:25 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 98A2128C14F for ; Thu, 2 Apr 2009 06:56:24 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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: <2265CB25-98CE-4C4C-9795-682E3200BBC2@cisco.com> 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: owner-ietf-provreg@cafax.se 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 jgould@verisign.com 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: Chris.Newman@Sun.COM [mailto:Chris.Newman@Sun.COM] >>> Sent: Tuesday, December 16, 2008 12:08 AM >>> To: Hollenbeck, Scott; lisa@osafoundation.org >>> Cc: ietf-provreg@cafax.se; iesg@ietf.org >>> 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:

  1. External hosts per Registrar, where an association f= rom domains to external hosts of another client (Registrar) is not allowed.
  2. 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
jgould@verisign.com
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 <paf@cisco.com>
> Date: Thu, 2 Apr 2009 08:49:06 -0400
> To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
> Cc: <Chris.Newman@Sun.COM>, E= PP Provreg <ietf-provreg@cafax.se>=
> 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: Chris.Newman@Sun.COM = [mailto:Chris.Newman@Sun.COM]
>>> Sent: Tuesday, December 16, 2008 12:08 AM
>>> To: Hollenbeck, Scott; lisa@o= safoundation.org
>>> Cc: ietf-provreg@cafax.se;= iesg@ietf.org
>>> 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;
>>> <shollenbeck@verisign.co= 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-- From owner-ietf-provreg@cafax.se Thu Apr 2 07:39:00 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 466B83A6D27 for ; Thu, 2 Apr 2009 07:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[AWL=0.598, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9Xvb7xe4lm0 for ; Thu, 2 Apr 2009 07:38:59 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id D3FB13A688A for ; Thu, 2 Apr 2009 07:38:58 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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 Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <046F43A8D79C794FA4733814869CDF07029A0E3C@dul1wnexmb01.vcorp.ad.vrsn.com> References: <046F43A8D79C794FA4733814869CDF07026523E3@dul1wnexmb01.vcorp.ad.vrsn.com> <046F43A8D79C794FA4733814869CDF07029A0E33@dul1wnexmb01.vcorp.ad.vrsn.com> <2265CB25-98CE-4C4C-9795-682E3200BBC2@cisco.com> <046F43A8D79C794FA4733814869CDF07029A0E3C@dul1wnexmb01.vcorp.ad.vrsn.com> 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: ed.lewis@Neustar.biz 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: owner-ietf-provreg@cafax.se 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:paf@cisco.com] >> Sent: Thursday, April 02, 2009 8:49 AM >> To: Hollenbeck, Scott >> Cc: Chris.Newman@Sun.COM; ietf-provreg@cafax.se >> 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: Chris.Newman@Sun.COM [mailto:Chris.Newman@Sun.COM] >> >> Sent: Tuesday, December 16, 2008 12:08 AM >> >> To: Hollenbeck, Scott; lisa@osafoundation.org >> >> Cc: ietf-provreg@cafax.se; iesg@ietf.org >> >> 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. From owner-ietf-provreg@cafax.se Thu Apr 2 10:14:54 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 932AC3A6AAD for ; Thu, 2 Apr 2009 10:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.148 X-Spam-Level: X-Spam-Status: No, score=-4.148 tagged_above=-999 required=5 tests=[AWL=-4.266, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Za0u0rDGbNDF for ; Thu, 2 Apr 2009 10:14:53 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 6D9E63A67D2 for ; Thu, 2 Apr 2009 10:14:53 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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: <49F7F63E-E756-4EF5-BAEF-8467810D8217@cisco.com> 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: <046F43A8D79C794FA4733814869CDF07026523E3@dul1wnexmb01.vcorp.ad.vrsn.com> <046F43A8D79C794FA4733814869CDF07029A0E33@dul1wnexmb01.vcorp.ad.vrsn.com> <2265CB25-98CE-4C4C-9795-682E3200BBC2@cisco.com> <046F43A8D79C794FA4733814869CDF07029A0E3C@dul1wnexmb01.vcorp.ad.vrsn.com> 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=paf@cisco.com; 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=paf@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Sender: owner-ietf-provreg@cafax.se 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-- From owner-ietf-provreg@cafax.se Thu Apr 2 10:16:15 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEB493A6DE5 for ; Thu, 2 Apr 2009 10:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.935 X-Spam-Level: X-Spam-Status: No, score=-3.935 tagged_above=-999 required=5 tests=[AWL=-4.053, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTnldiagE0nK for ; Thu, 2 Apr 2009 10:16:15 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 4C0513A6DDD for ; Thu, 2 Apr 2009 10:16:14 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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=paf@cisco.com; 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=paf@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-ietf-provreg@cafax.se 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-- From owner-ietf-provreg@cafax.se Thu Apr 2 10:48:24 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6439F3A67DA for ; Thu, 2 Apr 2009 10:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.122 X-Spam-Level: * X-Spam-Status: No, score=1.122 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_05=-1.11, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0ZLnI96Z1YO for ; Thu, 2 Apr 2009 10:48:13 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id CC9FC3A68E8 for ; Thu, 2 Apr 2009 10:48:02 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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: owner-ietf-provreg@cafax.se 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 jgould@verisign.com 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
jgould@verisign.com
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 <paf@cisco.com>
> Date: Thu, 2 Apr 2009 12:55:08 -0400
> To: James Gould <jgould@verisign.com<= /a>>
> Cc: "Hollenbeck, Scott" <shollenbeck@verisign.com>, <Chri= s.Newman@Sun.COM>,
> EPP Provreg <ietf-provreg@cafax.se<= /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-- From owner-ietf-provreg@cafax.se Thu Apr 2 11:51:05 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1DB53A68DC for ; Thu, 2 Apr 2009 11:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.742 X-Spam-Level: X-Spam-Status: No, score=-3.742 tagged_above=-999 required=5 tests=[AWL=-3.860, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rzbfEXOI2YW for ; Thu, 2 Apr 2009 11:51:04 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id AA28E3A6C31 for ; Thu, 2 Apr 2009 11:51:03 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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: <33002F21-8354-4E8F-A23A-DC35F58E5CC4@cisco.com> 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=paf@cisco.com; 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=paf@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-ietf-provreg@cafax.se 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-- From owner-ietf-provreg@cafax.se Thu Apr 2 15:50:02 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 996B53A6D53 for ; Thu, 2 Apr 2009 15:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.782 X-Spam-Level: X-Spam-Status: No, score=-1.782 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGLxnxr9vsSR for ; Thu, 2 Apr 2009 15:50:01 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 72B8A3A6824 for ; Thu, 2 Apr 2009 15:50:01 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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 brunner@nic-naa.net) Message-ID: <49D53EC2.1010606@nic-naa.net> 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" , Chris.Newman@Sun.COM, EPP Provreg Subject: Re: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs References: <33002F21-8354-4E8F-A23A-DC35F58E5CC4@cisco.com> In-Reply-To: <33002F21-8354-4E8F-A23A-DC35F58E5CC4@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se 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 From tifa@btinternet.com Fri Apr 3 00:39:23 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B9413A6C20; Fri, 3 Apr 2009 00:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -36.249 X-Spam-Level: X-Spam-Status: No, score=-36.249 tagged_above=-999 required=5 tests=[BAYES_60=1, HELO_EQ_DE=0.35, HELO_EQ_DSL=1.129, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, URIBL_BLACK=20, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNQNqPVUD64d; Fri, 3 Apr 2009 00:39:22 -0700 (PDT) Received: from g229125012.adsl.alicedsl.de (g229125012.adsl.alicedsl.de [92.229.125.12]) by core3.amsl.com (Postfix) with SMTP id A9BE93A6C24; Fri, 3 Apr 2009 00:39:11 -0700 (PDT) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 From: "Cheryl Barlow" To: "Harriet Ellis" Subject: Beautiful Vacheron Constantin watches for less Date: Fri, 03 Apr 2009 03:40:12 -0500 Message-Id: The new Porsche Design watches originated from the novel Titanium Chronogr= aph from the 1970's, an absolutely unique creation due to the perfection o= f its workmanship. Based on its design, the Porsche Design Company develop= ed an appealing, stylish, sporty and highly accurate watch. Unfortunately,= these timepieces come with a high price tag. http://biwuquciz.cn/ That's why a clever group of European manufacturers decided to offer the s= ame exact functionality and style at greatly reduced prices: the Porsche D= esign replica watches. These replicas are so similar to the brand name pie= ces that it is practically impossible to tell them apart, other than by th= eir price. They look the same, they function the same and they definitely = don't have the same prices :) How would you like to browse through an amaz= ing collection of these watches and marvel yourself with their low prices?= Visit Diamond Replicas and see for yourself why sometimes replicas are so= much better than the originals! http://biwuquciz.cn/ From advices@viceroy.com Fri Apr 3 02:05:49 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 543C33A6868; Fri, 3 Apr 2009 02:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.145 X-Spam-Level: ** X-Spam-Status: No, score=2.145 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_REPLICA_ROLEX=3.157, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DYNAMIC=1.144, HELO_EQ_TW=1.335, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5MhYn2Ylofi; Fri, 3 Apr 2009 02:05:48 -0700 (PDT) Received: from 123-195-88-75.dynamic.kbronet.com.tw (123-195-88-75.dynamic.kbronet.com.tw [123.195.88.75]) by core3.amsl.com (Postfix) with SMTP id 922A83A6968; Fri, 3 Apr 2009 02:05:26 -0700 (PDT) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 From: "Buford Blevins" To: "Ella Zamora" Subject: You can save 80% on Patek Phillipe Date: Fri, 03 Apr 2009 05:06:33 -0500 Message-Id: How about making your friends jealous and saving a lot of money doing it? = Forget about spending thousands of dollars on a new Rolex watch! Instead, = visit the newly redesigned Diamond Replicas and buy yourself a beautiful, = one of a kind Rolex Datejust watch! http://risukoqef.cn/ Of course, we're talking about replica watches, not the overpriced origina= ls... After all, our Rolex Datejusts offer the same precise functionality = and exact look than their costly counterparts, but you can buy yours for j= ust a couple of hundred bucks. So, come aboard Diamond Replicas and take a= dvantage of our extensive collection of replica Rolex watches, our superb = customer service and our super low prices! http://risukoqef.cn/ From owner-ietf-provreg@cafax.se Fri Apr 3 06:45:14 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C94D28C1FF for ; Fri, 3 Apr 2009 06:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.029 X-Spam-Level: * X-Spam-Status: No, score=1.029 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_05=-1.11, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THlsJO6Vf8kj for ; Fri, 3 Apr 2009 06:45:04 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 272BC28C126 for ; Fri, 3 Apr 2009 06:45:03 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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: <33002F21-8354-4E8F-A23A-DC35F58E5CC4@cisco.com> 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: owner-ietf-provreg@cafax.se 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 jgould@verisign.com 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:

  1. 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.  
  2. 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.  
  3. 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
jgould@verisign.com
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 <paf@cisco.com>
> Date: Thu, 2 Apr 2009 14:31:52 -0400
> To: James Gould <jgould@verisign.com<= /a>>
> Cc: "Hollenbeck, Scott" <shollenbeck@verisign.com>, <Chri= s.Newman@Sun.COM>,
> EPP Provreg <ietf-provreg@cafax.se<= /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-- From ls@abcr.org.br Fri Apr 3 11:00:15 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9637E28C16F for ; Fri, 3 Apr 2009 11:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.462 X-Spam-Level: *** X-Spam-Status: No, score=3.462 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nf-iYsCs6jgh for ; Fri, 3 Apr 2009 11:00:15 -0700 (PDT) Received: from 91-163-110-63.rev.libertysurf.net (91-163-110-63.rev.libertysurf.net [91.163.110.63]) by core3.amsl.com (Postfix) with SMTP id 89BF03A6B78 for ; Fri, 3 Apr 2009 11:00:14 -0700 (PDT) To: Subject: Credit card expired From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090403180014.89BF03A6B78@core3.amsl.com> Date: Fri, 3 Apr 2009 11:00:14 -0700 (PDT)
Subscribe to Men's Health Today!



Subscribe to Men's Health Today!





To your health,


David Zinczenko
Editor-in-Chief
Subscribe to Men's Health Today!
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street, Emmaus, PA 18098
From owner-ietf-provreg@cafax.se Fri Apr 3 12:24:18 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AC283A67D1 for ; Fri, 3 Apr 2009 12:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tk5pF5INaBqt for ; Fri, 3 Apr 2009 12:24:17 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 1B7133A69E6 for ; Fri, 3 Apr 2009 12:24:13 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029A0FC7@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, April 03, 2009 2:45 PM To: i-d-announce@ietf.org 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-- From ed890@yahoo.com Fri Apr 3 16:50:30 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE3BE3A69A3; Fri, 3 Apr 2009 16:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -24.458 X-Spam-Level: X-Spam-Status: No, score=-24.458 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaa1NYdblahz; Fri, 3 Apr 2009 16:50:29 -0700 (PDT) Received: from 173-17-204-157.client.mchsi.com (173-17-204-157.client.mchsi.com [173.17.204.157]) by core3.amsl.com (Postfix) with SMTP id E4B393A69AB; Fri, 3 Apr 2009 16:50:22 -0700 (PDT) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 From: "Nelson Pacheco" To: "Giovanni Oneil" Subject: Save thousands... no one will know Date: Fri, 03 Apr 2009 19:51:25 -0500 Message-Id: The new Porsche Design watches originated from the novel Titanium Chronogr= aph from the 1970's, an absolutely unique creation due to the perfection o= f its workmanship. Based on its design, the Porsche Design Company develop= ed an appealing, stylish, sporty and highly accurate watch. Unfortunately,= these timepieces come with a high price tag. http://jifotidaj.cn/ That's why a clever group of European manufacturers decided to offer the s= ame exact functionality and style at greatly reduced prices: the Porsche D= esign replica watches. These replicas are so similar to the brand name pie= ces that it is practically impossible to tell them apart, other than by th= eir price. They look the same, they function the same and they definitely = don't have the same prices :) How would you like to browse through an amaz= ing collection of these watches and marvel yourself with their low prices?= Visit Diamond Replicas and see for yourself why sometimes replicas are so= much better than the originals! http://jifotidaj.cn/ From cahelp@sdcpdx.com Fri Apr 3 17:50:57 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5DB3A6932; Fri, 3 Apr 2009 17:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3D8vZF7queYk; Fri, 3 Apr 2009 17:50:56 -0700 (PDT) Received: from adsl196-137-186-206-196.adsl196-6.iam.net.ma (adsl196-137-186-206-196.adsl196-6.iam.net.ma [196.206.186.137]) by core3.amsl.com (Postfix) with SMTP id 47BD53A68CF; Fri, 3 Apr 2009 17:50:41 -0700 (PDT) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 From: "Earle Dickey" To: "Benjamin Lowe" Subject: Winter quality watches offer Date: Fri, 03 Apr 2009 20:51:49 -0500 Message-Id: A Breitling watch is a statement not just of wealth, but of sophistication= .. it's a way to show the world that you are a man in charge of your life= and that you know exactly what you want. Surely, among those things you d= o want is a bigger budget. So, why not kill two birds with one stone? Gett= ing a replica Breitling wristwatch and keeping your budget practically unt= ouched! http://mijufufod.cn/ Thanks to Diamond Replicas it is now possible! With an astonishing collect= ion of replica Breitling timepieces at rock bottom prices, Diamond Replica= s will make the delights of quality watches lovers. It offers excellent qu= ality timepieces at unsurpassed prices; a privacy-assured guarantee, incom= parable customer service, and what's better: 15% off when you buy two watc= hes! http://mijufufod.cn/ From jenniferl@advhyd.com Fri Apr 3 22:51:25 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80D283A67DD for ; Fri, 3 Apr 2009 22:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.72 X-Spam-Level: X-Spam-Status: No, score=-8.72 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_RU=0.595, HELO_IS_SMALL6=0.556, HELO_MISMATCH_RU=3.1, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcQ-V34-GKjF for ; Fri, 3 Apr 2009 22:51:24 -0700 (PDT) Received: from alko.ru (unknown [58.108.162.121]) by core3.amsl.com (Postfix) with SMTP id C463E3A6768 for ; Fri, 3 Apr 2009 22:51:23 -0700 (PDT) To: Subject: Bank loan information From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090404055123.C463E3A6768@core3.amsl.com> Date: Fri, 3 Apr 2009 22:51:23 -0700 (PDT)
Subscribe to Men's Health Today!



Subscribe to Men's Health Today!





To your health,


David Zinczenko
Editor-in-Chief
Subscribe to Men's Health Today!
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street, Emmaus, PA 18098
From owner-ietf-provreg@cafax.se Sat Apr 4 00:46:59 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CED223A68EF for ; Sat, 4 Apr 2009 00:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.579 X-Spam-Level: X-Spam-Status: No, score=-4.579 tagged_above=-999 required=5 tests=[AWL=-2.630, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJ6oa-b8HHol for ; Sat, 4 Apr 2009 00:46:58 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 5DA9C3A6768 for ; Sat, 4 Apr 2009 00:46:58 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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: <8803B199-A11C-4CCB-A104-61E041143A65@cisco.com> 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=paf@cisco.com; 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=paf@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-ietf-provreg@cafax.se 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-- From orphouslydomesticated@aamainc.us Sat Apr 4 11:22:50 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BB9F3A6A4F for ; Sat, 4 Apr 2009 11:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.645 X-Spam-Level: X-Spam-Status: No, score=-3.645 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42cEhqmuWp3o for ; Sat, 4 Apr 2009 11:22:49 -0700 (PDT) Received: from host-89-228-130-138.gorzow.mm.pl (host-89-228-130-138.gorzow.mm.pl [89.228.130.138]) by core3.amsl.com (Postfix) with SMTP id A23A23A6963 for ; Sat, 4 Apr 2009 11:22:48 -0700 (PDT) To: Subject: Credit card expired From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090404182248.A23A23A6963@core3.amsl.com> Date: Sat, 4 Apr 2009 11:22:48 -0700 (PDT)

Subscribe to Men's Health Today!



Subscribe to Men's Health Today!





To your health,


David Zinczenko
Editor-in-Chief
Subscribe to Men's Health Today!
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street, Emmaus, PA 18098
From llbjab@aamu.edu Sun Apr 5 12:45:40 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D03B3A6ACA for ; Sun, 5 Apr 2009 12:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.373 X-Spam-Level: X-Spam-Status: No, score=-8.373 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SUB_POOR_CREDIT=1.121, SUBJ_YOUR_DEBT=2.622, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rMqp8m02AR6 for ; Sun, 5 Apr 2009 12:45:35 -0700 (PDT) Received: from host135-133-dynamic.4-87-r.retail.telecomitalia.it (host135-133-dynamic.4-87-r.retail.telecomitalia.it [87.4.133.135]) by core3.amsl.com (Postfix) with SMTP id A1CC13A686A for ; Sun, 5 Apr 2009 12:45:32 -0700 (PDT) To: Subject: Your credit card balance limit From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090405194533.A1CC13A686A@core3.amsl.com> Date: Sun, 5 Apr 2009 12:45:32 -0700 (PDT)
Subscribe to Men's Health Today!



Subscribe to Men's Health Today!





To your health,


David Zinczenko
Editor-in-Chief
Subscribe to Men's Health Today!
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street, Emmaus, PA 18098
From owner-ietf-provreg@cafax.se Mon Apr 6 08:30:03 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0EFC3A6CA8 for ; Mon, 6 Apr 2009 08:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjaDy7z5NMPK for ; Mon, 6 Apr 2009 08:30:03 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id C77423A6C81 for ; Mon, 6 Apr 2009 08:30:02 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029A105E@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, April 06, 2009 11:00 AM To: i-d-announce@ietf.org 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-- From owner-ietf-provreg@cafax.se Mon Apr 6 08:30:26 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C09CA28C209 for ; Mon, 6 Apr 2009 08:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViiID7BPuqf2 for ; Mon, 6 Apr 2009 08:30:25 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 064C728C206 for ; Mon, 6 Apr 2009 08:30:24 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029A1060@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, April 06, 2009 11:00 AM To: i-d-announce@ietf.org 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-- From owner-ietf-provreg@cafax.se Mon Apr 6 08:31:25 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 779F528C20A for ; Mon, 6 Apr 2009 08:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWc3IxHfOFzR for ; Mon, 6 Apr 2009 08:31:18 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 6E1EC28C208 for ; Mon, 6 Apr 2009 08:31:18 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029A105F@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, April 06, 2009 11:00 AM To: i-d-announce@ietf.org 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-- From owner-ietf-provreg@cafax.se Mon Apr 6 10:23:49 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2A4228C1E4 for ; Mon, 6 Apr 2009 10:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yz4XTsyw3Wqe for ; Mon, 6 Apr 2009 10:23:43 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 6455F3A6CE4 for ; Mon, 6 Apr 2009 10:23:09 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029A107B@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, April 06, 2009 12:45 PM To: i-d-announce@ietf.org 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-- From operkins@allconet.org Tue Apr 7 04:00:35 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DEF73A69D6 for ; Tue, 7 Apr 2009 04:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -83.528 X-Spam-Level: X-Spam-Status: No, score=-83.528 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_IMG_ONLY=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrA2U05K4q41 for ; Tue, 7 Apr 2009 04:00:34 -0700 (PDT) Received: from alexgarvin.net (unknown [79.107.65.182]) by core3.amsl.com (Postfix) with SMTP id C3C6A3A6DAA for ; Tue, 7 Apr 2009 04:00:33 -0700 (PDT) To: Subject: Hey cute From: me MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090407110033.C3C6A3A6DAA@core3.amsl.com> Date: Tue, 7 Apr 2009 04:00:33 -0700 (PDT) Teen Beautiful Blonde will get acquainted with good guy (or guys) for chat and real meetings!

My real Photo:

 Click for mail me!

My E-mail: 4spb@zvdeeeev.com

 From info@hp.com Wed Apr 8 05:36:00 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 491BA3A6B0F for ; Wed, 8 Apr 2009 05:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -84.84 X-Spam-Level: X-Spam-Status: No, score=-84.84 tagged_above=-999 required=5 tests=[BASE64_LENGTH_79_INF=1.496, BAYES_99=3.5, HELO_MISMATCH_COM=0.553, HOST_EQ_BR=1.295, INVALID_MSGID=1.9, MIME_BASE64_TEXT=1.753, RCVD_IN_PBL=0.905, SARE_RECV_VIRTUACOMBR=1.193, SARE_SUB_ENC_WIN1251=1.666, SARE_SUB_GET_PAID=0.899, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ei5HuLr-VvxY for ; Wed, 8 Apr 2009 05:35:59 -0700 (PDT) Received: from google.com (c951a080.virtua.com.br [201.81.160.128]) by core3.amsl.com (Postfix) with ESMTP id 83B953A6AB3 for ; Wed, 8 Apr 2009 05:35:55 -0700 (PDT) Received: from [107.180.70.91] (HELO google.com) by wise-buzzer.com; Wed, 8 Apr 2009 09:33:02 -0300 Date: Wed, 8 Apr 2009 09:33:02 -0300 From: Anne Haile X-Mailer: The Bat! (v2.01) Reply-To: Anne Haile X-Priority: 3 (Normal) Message-ID: <00000004348E9BE787156155> To: Subject: =?windows-1251?B?U2hhcmUgeW91ciBvcGluaW9uIGFuZCBHZXQgUGFpZCE=?= MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: base64 RG8geW91IHdhbnQgdG8gZ2V0IHBhaWQgYnkgbWFqb3Igb25saW5lIHJldGFpbGVycyBmb3IgZG9pbmcgc29tZSBzaW1wbGUgb25saW5lIHN1cnZleXM/DQoNCkFsbCB5b3UgbmVlZCBpcyBhIGxpdHRsZSBmcmVlIHRpbWUgdG8gc3RhdGUgeW91ciBob25lc3Qgb3BpbmlvbiBvbiB0aGUgdG9waWNzIHByb3ZpZGVkLg0KDQpJZiB5b3UgZG8gbGlrZSB0byBiZWNvbWUgb25lIG9mIG91ciBoaWdobHkgdmFsdWVkIHN1cnZleSB0YWtlcnMsIHBsZWFzZSBlLW1haWwgdXMgYmFjayB0byAxNTMyMmh1bHN0cmFuZG1hcmdhcmV0QGdtYWlsLmNvbSBhbmQgd2Ugd2lsbCBzZW5kIHlvdSBhZGRpdGlvbmFsIGluZm9ybWF0aW9uLg0KDQpUaGlzIGlzIGEgc2VyaW91cyBhbmQgc2luY2VyZSBpbnF1aXJ5LiBUaGUgYXZhaWxhYmxlIGZyZWUgcGxhY2VzIGFyZSB2ZXJ5IGxpbWl0ZWQgc28gaHVycnkgdXAgaWYgeW91IHdhbnQgdG8gYmUgYSBwYXJ0IQ0KDQpLaW5kZXN0IHJlZ2FyZHMsDQpDb25zdW1lciBPcGluaW9uIEFkbWluaXN0cmF0aW9uCgoKCgoKCgoKCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tClRoaXMgZW1haWwgaGFzIGJlZW4gd3JpdHRlbiBhbmQgcHJvdmVkIHRvIGJlIGluIGNvbXBsaWFuY2Ugd2l0aCB0aGUgcmVjZW50bHkgZXN0YWJsaXNoZWQgY2FuLXNwYW0gYWN0IGxhdyBpbiBVUy4gV2UgYXJlIG5vdCBwcm92b2tpbmcgb3IgZm 9yY2luZyBhbnkgcGVyc29uIGluIGFueSB3YXkgdG8gcGFydGljaXBhdGUgaW4gb3VyIHByb2dyYW1zLiBUbyBwYXJ0aWNpcGF0ZSBpcyB5b3VyIG93biBkZWNpc2lvbiBhbmQgeW91IGNhcnJ5IHRoZSByZXNwb25zaWJpbGl0eSBvZiB0YWtpbmcgZnVydGhlciBwYXJ0IGluIHRoaXMgcHJvbW90aW9uLiBBbnl3YXksIGlmIHlvdSBkb24ndCB3YW50IHRvIHJlY2VpdmUgbW9yZSBnb29kIG9mZmVycyBmcm9tIHVzLCB5b3UgY2FuIHNpbXBseSBVbnN1YnNjcmliZSBieSBzZW5kaW5nIHVzIGEgbm90aWZpY2F0aW9uIGVtYWlsIHRvIHNpZ24ub3V0X21lQHlhaG9vLmNvbSB3aXRoIGEgbWFpbC1zdWJqZWN0IGFuZCB0ZXh0ICJVbnN1YnNjcmliZSBtZSIsIGFuZCB3ZSB3aWxsIGdldCB5b3VyIGVtYWlsIG91dCBvZiBvdXIgbGlzdCB3aXRoaW4gMTAgZGF5cy4KClRoaXMgbWVzc2FnZSBpcyBTVFJJQ1RMWSBDT05GSURFTlRJQUwgYW5kIGlzIHNvbGVseSBmb3IgdGhlIGluZGl2aWR1YWwgb3Igb3JnYW5pc2F0aW9uIHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiBQUklWSUxFR0VEIGFuZCBDT05GSURFTlRJQUwgaW5mb3JtYXRpb24uIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBhbmQgaXRzIGNvbnR lbnRzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgeW91IHNob3VsZCBub3QgcmVhZCwgY29weSwgZGlzdHJpYnV0ZSwgZGlzY2xvc2Ugb3Igb3RoZXJ3aXNlIHVzZSB0aGUgaW5mb3JtYXRpb24gaW4gdGhpcyBlbWFpbC4gRW1haWwgbWF5IGJlIHN1c2NlcHRpYmxlIHRvIGRhdGEgY29ycnVwdGlvbiwgaW50ZXJjZXB0aW9uIGFuZCB1bmF1dGhvcmlzZWQgYW1lbmRtZW50LCBhbmQgd2UgZG8gbm90IGFjY2VwdCBsaWFiaWxpdHkgZm9yIGFueSBzdWNoIGNvcnJ1cHRpb24sIGludGVyY2VwdGlvbiBvciBhbWVuZG1lbnQgb3IgdGhlIGNvbnNlcXVlbmNlcyB0aGVyZW9mIG9yIHlvdXIgcmVsaWFuY2Ugb24gYW55IGluZm9ybWF0aW9uIGNvbnRhaW5lZCB0aGVyZWluIGlmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIElmIHlvdSBhcmUgbm90IGludGVyZXN0ZWQgaW4gdGhlIG9mZmVyZWQgcHJvbW90aW9ucywgcGxlYXNlIGp1c3QgZG9uJ3QgYW5zd2VyLiBJZiB5b3UgdGhpbmsgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGFuZCBpdHMgY29udGVudHMgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIGNvbXB1dGVyLCBvciBmb2xsb3cgdGhlIHVuc3Vic2NyaWJpbmcgcHJvY2VkdXJlIHNob3duIGFib3ZlLgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KCQk= From officej@alpquell.com Fri Apr 10 06:33:19 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EE253A68F1 for ; Fri, 10 Apr 2009 06:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -39.536 X-Spam-Level: X-Spam-Status: No, score=-39.536 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIijlyabJ5-q for ; Fri, 10 Apr 2009 06:33:19 -0700 (PDT) Received: from 3birds7men.com (unknown [93.188.9.34]) by core3.amsl.com (Postfix) with SMTP id 9E7903A6D92 for ; Fri, 10 Apr 2009 06:33:16 -0700 (PDT) To: Subject: Sales Receipt Amazon From: VIAGRA . Official Site MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090410133317.9E7903A6D92@core3.amsl.com> Date: Fri, 10 Apr 2009 06:33:16 -0700 (PDT)
Men's Health wirzpBuild Maximum MUSCLE, STRENGTH, and POWER!
Try It FREE for 21 Days! ORDER NOW! Plus, get 2 FREE Bonus Gifts!
Dear provreg-archive

Men's Health recommends


FREE gifts reserved for you: provreg-archive@ietf.org
If you would prefer not to receive future information about special offers from Men's Health,
you may Unsubscribe.


Customer Service Department, 33 East Minor Street, Emmaus, PA 18098


Copyright, Men's Health
From koueikasei@ai.tnc.ne.jp Fri Apr 10 10:17:47 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BAB93A6EFE for ; Fri, 10 Apr 2009 10:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -74.287 X-Spam-Level: X-Spam-Status: No, score=-74.287 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_IMG_ONLY=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXGDyvlTzW55 for ; Fri, 10 Apr 2009 10:17:46 -0700 (PDT) Received: from pool-71-249-73-28.nycmny.east.verizon.net (pool-71-249-73-28.nycmny.east.verizon.net [71.249.73.28]) by core3.amsl.com (Postfix) with SMTP id 5AB6F3A6F0F for ; Fri, 10 Apr 2009 10:16:30 -0700 (PDT) To: Subject: Why you dont take your phone? From: me MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090410171631.5AB6F3A6F0F@core3.amsl.com> Date: Fri, 10 Apr 2009 10:16:30 -0700 (PDT) I want to chat or meet you in real!
My real Photo:
Click for mail me!

My E-mail: G6ub@correctdate.com

 From jonahromanowide@advantageoffice.net Sun Apr 12 17:51:06 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51B4D3A6C5E for ; Sun, 12 Apr 2009 17:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.781 X-Spam-Level: X-Spam-Status: No, score=-10.781 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RzWRwRU8pOq for ; Sun, 12 Apr 2009 17:51:04 -0700 (PDT) Received: from pool-141-153-132-233.nwrk.east.verizon.net (pool-141-153-132-233.nwrk.east.verizon.net [141.153.132.233]) by core3.amsl.com (Postfix) with SMTP id 71DB43A6C25 for ; Sun, 12 Apr 2009 17:51:00 -0700 (PDT) To: Subject: Customer Receipt/Purchase Confirmation From: VIAGRA . Official Site MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090413005100.71DB43A6C25@core3.amsl.com> Date: Sun, 12 Apr 2009 17:51:00 -0700 (PDT)
Men's Health wirzpBuild Maximum MUSCLE, STRENGTH, and POWER!
Try It FREE for 21 Days! ORDER NOW! Plus, get 2 FREE Bonus Gifts!
Dear provreg-archive

Men's Health recommends


FREE gifts reserved for you: provreg-archive@ietf.org
If you would prefer not to receive future information about special offers from Men's Health,
you may Unsubscribe.


Customer Service Department, 33 East Minor Street, Emmaus, PA 18098


Copyright, Men's Health
From owner-ietf-provreg@cafax.se Mon Apr 13 05:51:08 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 730873A6D78 for ; Mon, 13 Apr 2009 05:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujXgTxZB1vei for ; Mon, 13 Apr 2009 05:51:07 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id CAF643A6B07 for ; Mon, 13 Apr 2009 05:51:06 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029FD625@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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- From owner-ietf-provreg@cafax.se Mon Apr 13 15:06:58 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CB8A3A6800 for ; Mon, 13 Apr 2009 15:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.104 X-Spam-Level: X-Spam-Status: No, score=0.104 tagged_above=-999 required=5 tests=[AWL=0.956, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6nvv3v-tcts for ; Mon, 13 Apr 2009 15:06:52 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 542573A67B1 for ; Mon, 13 Apr 2009 15:06:51 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029FD625@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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 jgould@verisign.com 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
jgould@verisign.com
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; <shollenbeck@verisign.com>= ;
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-- From owner-ietf-provreg@cafax.se Tue Apr 14 04:34:36 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A94EA3A6840 for ; Tue, 14 Apr 2009 04:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.485 X-Spam-Level: X-Spam-Status: No, score=-1.485 tagged_above=-999 required=5 tests=[AWL=-0.726, BAYES_05=-1.11, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFkFjFhqIDcz for ; Tue, 14 Apr 2009 04:34:30 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id B38123A6D3E for ; Tue, 14 Apr 2009 04:34:29 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029FD729@dul1wnexmb01.vcorp.ad.vrsn.com> 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: <046F43A8D79C794FA4733814869CDF07029FD625@dul1wnexmb01.vcorp.ad.vrsn.com> From: "Hollenbeck, Scott" To: "Gould, James" , "EPP Provreg" X-OriginalArrivalTime: 14 Apr 2009 11:14:59.0229 (UTC) FILETIME=[3F9F6CD0:01C9BCF2] Sender: owner-ietf-provreg@cafax.se 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 jgould@verisign.com 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
jgould@verisign.com
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" <shollenbeck@verisign.com>
= Date:=20 Mon, 13 Apr 2009 08:37:25 -0400
To: EPP Provreg <ietf-provreg@cafax.se>
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-- From owner-ietf-provreg@cafax.se Tue Apr 14 06:25:58 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2C6B3A67B6 for ; Tue, 14 Apr 2009 06:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9LUusOIUjny for ; Tue, 14 Apr 2009 06:25:57 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id F1FDA3A69DD for ; Tue, 14 Apr 2009 06:25:44 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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 provreg@contact.dotandco.com 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: <20090414131105.GA6802@home.patoche.org> References: <046F43A8D79C794FA4733814869CDF07029FD625@dul1wnexmb01.vcorp.ad.vrsn.com> <046F43A8D79C794FA4733814869CDF07029FD729@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <046F43A8D79C794FA4733814869CDF07029FD729@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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 From owner-ietf-provreg@cafax.se Tue Apr 14 06:39:52 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61D6B3A6AD0 for ; Tue, 14 Apr 2009 06:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5S6GlvcwFMj9 for ; Tue, 14 Apr 2009 06:39:51 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 10AC63A6A9E for ; Tue, 14 Apr 2009 06:39:50 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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 provreg@contact.dotandco.com using -f Date: Tue, 14 Apr 2009 15:23:30 +0200 From: Patrick Mevzek To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] AD Review Comments: draft-hollenbeck-rfc4934bis-00 Message-ID: <20090414132330.GB6802@home.patoche.org> References: <046F43A8D79C794FA4733814869CDF07029FD625@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <046F43A8D79C794FA4733814869CDF07029FD625@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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 From owner-ietf-provreg@cafax.se Tue Apr 14 06:40:06 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56F9B3A6BAC for ; Tue, 14 Apr 2009 06:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.135 X-Spam-Level: X-Spam-Status: No, score=-0.135 tagged_above=-999 required=5 tests=[AWL=0.717, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qlKvdzHFkaN for ; Tue, 14 Apr 2009 06:39:58 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 340EA3A6A37 for ; Tue, 14 Apr 2009 06:39:58 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029FD729@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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 jgould@verisign.com 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 > jgould@verisign.com > 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
jgould@verisign.com
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; <shollenbeck@verisign.com>= ;
Date: Tue, 14 Apr 2009 07:14:58 -0400
To: James Gould <jgould@verisign.co= 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
jgould@verisign.com
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= " <shollenbeck@verisign.com&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-- From owner-ietf-provreg@cafax.se Wed Apr 15 06:12:14 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EF283A6A4B for ; Wed, 15 Apr 2009 06:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8slhGAaXzGr for ; Wed, 15 Apr 2009 06:12:13 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 2EEA93A6972 for ; Wed, 15 Apr 2009 06:12:12 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029FD808@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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:alexey.melnikov@isode.com] 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:alexey.melnikov@isode.com] >>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)? >> >> From owner-ietf-provreg@cafax.se Wed Apr 15 08:48:41 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27F043A6B3F for ; Wed, 15 Apr 2009 08:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.278 X-Spam-Level: X-Spam-Status: No, score=-0.278 tagged_above=-999 required=5 tests=[AWL=0.574, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TM3V9ONSp9B for ; Wed, 15 Apr 2009 08:48:39 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 518B63A6B0F for ; Wed, 15 Apr 2009 08:48:39 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029FD808@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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 jgould@verisign.com 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:alexey.melnikov@isode.com] 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:alexey.melnikov@isode.com] >>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 Re: [ietf-provreg] FW: Standards Track Advancement Request for EPP R= FCs 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
jgould@verisign.com
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; <shollenbeck@verisign.com>= ;
Date: Wed, 15 Apr 2009 09:00:22 -0400
To: EPP Provreg <ietf-provreg@caf= ax.se>
Cc: Alexey Melnikov <alexey.m= elnikov@isode.com>
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= exey.melnikov@isode.com]
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:alexey.melnikov@isode.com]
>>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-- From owner-ietf-provreg@cafax.se Wed Apr 15 12:08:43 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A73EC3A6B24 for ; Wed, 15 Apr 2009 12:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.744 X-Spam-Level: X-Spam-Status: No, score=-0.744 tagged_above=-999 required=5 tests=[AWL=-0.354, BAYES_20=-0.74, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCNGByU33HFs for ; Wed, 15 Apr 2009 12:08:43 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id C516B3A6C1A for ; Wed, 15 Apr 2009 12:08:42 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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 Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Wed, 15 Apr 2009 14:50:41 -0400 To: ietf-provreg@cafax.se From: Edward Lewis Subject: [ietf-provreg] who's running the list? Cc: ed.lewis@Neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-ietf-provreg@cafax.se 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. From owner-ietf-provreg@cafax.se Wed Apr 15 12:38:32 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A714628C1ED for ; Wed, 15 Apr 2009 12:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpYTOINpAwGA for ; Wed, 15 Apr 2009 12:38:31 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 6D8C93A6B07 for ; Wed, 15 Apr 2009 12:38:31 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029FD862@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se Precedence: bulk I believe the guy you're looking for is Lars-Johan Liman: http://www.cafax.se/~liman/ -Scott- > -----Original Message----- > From: owner-ietf-provreg@cafax.se > [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Edward Lewis > Sent: Wednesday, April 15, 2009 2:51 PM > To: ietf-provreg@cafax.se > Cc: ed.lewis@neustar.biz > 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. > From owner-ietf-provreg@cafax.se Wed Apr 15 12:52:21 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15ABB3A6F37 for ; Wed, 15 Apr 2009 12:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[AWL=-0.882, BAYES_05=-1.11, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkRblpCr3FoE for ; Wed, 15 Apr 2009 12:52:06 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 2F2993A6C1A for ; Wed, 15 Apr 2009 12:52:05 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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 jaap@bartok.nlnetlabs.nl) Message-Id: <200904151938.n3FJcg8F095212@bartok.nlnetlabs.nl> To: Edward Lewis cc: ietf-provreg@cafax.se 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) Sender: owner-ietf-provreg@cafax.se 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 From owner-ietf-provreg@cafax.se Wed Apr 15 14:58:00 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B20103A6A92 for ; Wed, 15 Apr 2009 14:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLVaLvmy+jCi for ; Wed, 15 Apr 2009 14:57:59 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 7ABB73A6831 for ; Wed, 15 Apr 2009 14:57:59 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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 jaap@bartok.nlnetlabs.nl) Message-Id: <200904152145.n3FLjAkQ034555@bartok.nlnetlabs.nl> To: ietf-provreg@cafax.se 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) Sender: owner-ietf-provreg@cafax.se 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 ietf-proveg-request@cafax.se From kahanur@777stor.com Thu Apr 16 21:12:44 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AF223A698A for ; Thu, 16 Apr 2009 21:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.206 X-Spam-Level: X-Spam-Status: No, score=-7.206 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLUR0fvlEgSa for ; Thu, 16 Apr 2009 21:12:37 -0700 (PDT) Received: from c-98-247-214-208.hsd1.wa.comcast.net (c-98-247-214-208.hsd1.wa.comcast.net [98.247.214.208]) by core3.amsl.com (Postfix) with SMTP id 213693A6925 for ; Thu, 16 Apr 2009 21:12:36 -0700 (PDT) To: provreg-archive@ietf.org Subject: from provreg-archive@ietf.org From: provreg-archive@ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090417041237.213693A6925@core3.amsl.com> Date: Thu, 16 Apr 2009 21:12:36 -0700 (PDT)
Tell a friend · Download latest version See this email as a webpage

Hello!

Shipped Privately And Discreetly To Your Door!
See this email as a webpage
  We want to put a great big grin on your face in 2009. You'll be to rejoice all year.  

Unsubscribe · Lost Password · Account Settings · Help · Terms of Service · Privacy

Ottho Heldringstraat 0, 91143 AZ Amsterdam, The Netherlands
From maarouf.bellazizi@amour.fr Fri Apr 17 11:27:55 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AE6C3A68B0 for ; Fri, 17 Apr 2009 11:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.136 X-Spam-Level: X-Spam-Status: No, score=-5.136 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olKY03R2xuxE for ; Fri, 17 Apr 2009 11:27:49 -0700 (PDT) Received: from 163-56-179-94.pool.ukrtel.net (163-56-179-94.pool.ukrtel.net [94.179.56.163]) by core3.amsl.com (Postfix) with SMTP id 883773A6844 for ; Fri, 17 Apr 2009 11:27:42 -0700 (PDT) To: " Date: Fri, 17 Apr 2009 11:27:42 -0700 (PDT)
Men's Health wirzpBuild Maximum MUSCLE, STRENGTH, and POWER!
Try It FREE for 21 Days! ORDER NOW! Plus, get 2 FREE Bonus Gifts!
Dear provreg-archive

Men's Health recommends


FREE gifts reserved for you: provreg-archive@ietf.org
If you would prefer not to receive future information about special offers from Men's Health,
you may Unsubscribe.


Customer Service Department, 33 East Minor Street, Emmaus, PA 18098


Copyright, Men's Health
From a.westphal@sharpness.de Fri Apr 17 20:51:15 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73B5C3A6AEA; Fri, 17 Apr 2009 20:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.798 X-Spam-Level: X-Spam-Status: No, score=-20.798 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_ROLEX=5, HELO_EQ_IT=0.635, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_42=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN0b=1.666, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_NOV5F=0.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAjqUlgkEmJG; Fri, 17 Apr 2009 20:51:14 -0700 (PDT) Received: from tassani.it (118-171-76-250.dynamic.hinet.net [118.171.76.250]) by core3.amsl.com (Postfix) with ESMTP id EE45D3A6BA0; Fri, 17 Apr 2009 20:51:12 -0700 (PDT) Message-ID: Date: Fri, 17 Apr 2009 23:52:19 -0500 From: "Dubois Greg" TO: <"mailman@ietf.org, xcon@ietf.org, kink-archive@ietf.org, provreg-archive@ietf.org, nsis-request@ietf.org, pana@ietf.org, rpsec-bounces@ietf.org, sigtran-bounces@ietf.org, tsvwg"@ietf.org> Subject: Hot rep watches from 2009 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit So you thought owning a brand name watch was out of your reach? Think again! http://www.xuwemowam.cn Diam0nd Reps has it all: Rolex, Cartier, Tag Heuer, Breitling, and many more, for a fraction of the price of an original watch. And don't forget: when you order two watches, you get an extra 15 percent discount over our already low prices! http://www.xuwemowam.cn Don't believe me? Click here to enter Diam0nd Reps right now, and see it with your very own eyes! From lornament@amdyne.net Sun Apr 19 05:53:16 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EE423A6F13 for ; Sun, 19 Apr 2009 05:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.466 X-Spam-Level: X-Spam-Status: No, score=-5.466 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_JP=1.244, HELO_EQ_NE_JP=1.244, HOST_EQ_JP=1.265, HOST_EQ_NE_JP=2.599, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3AIg13oXwjB for ; Sun, 19 Apr 2009 05:53:10 -0700 (PDT) Received: from p3225-ipbf603akatuka.ibaraki.ocn.ne.jp (p3225-ipbf603akatuka.ibaraki.ocn.ne.jp [122.24.228.225]) by core3.amsl.com (Postfix) with SMTP id 697503A68B3 for ; Sun, 19 Apr 2009 05:53:08 -0700 (PDT) To: Subject: Sales Receipt Amazon From: VIAGRA . Official Site MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090419125309.697503A68B3@core3.amsl.com> Date: Sun, 19 Apr 2009 05:53:08 -0700 (PDT)
Men's Health wirzpBuild Maximum MUSCLE, STRENGTH, and POWER!
Try It FREE for 21 Days! ORDER NOW! Plus, get 2 FREE Bonus Gifts!
Dear provreg-archive

Men's Health recommends


FREE gifts reserved for you: provreg-archive@ietf.org
If you would prefer not to receive future information about special offers from Men's Health,
you may Unsubscribe.


Customer Service Department, 33 East Minor Street, Emmaus, PA 18098


Copyright, Men's Health
From arileek@midwisc.com Sun Apr 19 18:11:35 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F0C23A6B6B; Sun, 19 Apr 2009 18:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.597 X-Spam-Level: X-Spam-Status: No, score=-21.597 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_42=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN0b=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YokQmXd1rSD; Sun, 19 Apr 2009 18:11:34 -0700 (PDT) Received: from cmecwuxi.com (218-169-4-230.dynamic.hinet.net [218.169.4.230]) by core3.amsl.com (Postfix) with ESMTP id BA34D3A6EA9; Sun, 19 Apr 2009 18:11:32 -0700 (PDT) Message-ID: Date: Sun, 19 Apr 2009 21:12:49 -0500 From: "Barrett Ervin" TO: <"ldap-dir-bounces@ietf.org, vpn-dir@ietf.org, mailman@ietf.org, xcon@ietf.org, kink-archive@ietf.org, provreg-archive@ietf.org, nsis-request@ietf.org, pana@ietf.org, rpsec-bounces"@ietf.org> Subject: Get 15% off these watches Content-Type: text/plain; Content-Transfer-Encoding: 7Bit There's no time like the present, and isn't it time you got yourself a beautiful designer watch? http://www.setasuvox.cn Visit Diam0nd Reps today and get a terrific designer watch imitation for a uniquely low price. Our watches are the most sought-after in the market, offering you the best performance and unsurpassed quality while allowing you to choose from hundreds of models within dozens of brands! http://www.setasuvox.cn Enjoy the fastest shipping around, paired with secure billing, incredible customer service and the largest online selection of fine reproduction timepieces only at Diam0nd Reps, of course! From owner-ietf-provreg@cafax.se Mon Apr 20 06:05:32 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5014B3A693E for ; Mon, 20 Apr 2009 06:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.168 X-Spam-Level: X-Spam-Status: No, score=-2.168 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hgUa+27MCWy for ; Mon, 20 Apr 2009 06:05:31 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 271323A68AE for ; Mon, 20 Apr 2009 06:05:30 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029FDA56@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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 ietf-provreg-request@cafax.se From a.toth@szalmanet.com Tue Apr 21 04:34:59 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE0563A7030; Tue, 21 Apr 2009 04:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -37.237 X-Spam-Level: X-Spam-Status: No, score=-37.237 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_ALMOST_IP=1.889, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, HOST_EQ_STATIC=1.172, HOST_EQ_STATICIP=1.511, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_42=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBOrEhlDAeAv; Tue, 21 Apr 2009 04:34:59 -0700 (PDT) Received: from verkaart.nl (86.Red-88-28-40.staticIP.rima-tde.net [88.28.40.86]) by core3.amsl.com (Postfix) with ESMTP id B7C3C3A700A; Tue, 21 Apr 2009 04:34:53 -0700 (PDT) Message-ID: Date: Tue, 21 Apr 2009 07:36:04 -0500 From: "Butcher Aurelio" TO: <"vpn-dir@ietf.org, mailman@ietf.org, xcon@ietf.org, kink-archive@ietf.org, provreg-archive"@ietf.org> Subject: watches wholesale all year long! Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Why waste your hard-earned money on an expensive watch when you can have the next best thing for a tenth of its price? http://www.uipzqhao.cn Take advantage of Diam0nd Reps tremendous specials, and get yourself a superb designer watch imitation for just a couple of hundred bucks. Plus an extra 15 percent discount when you get two time pieces in the same purchase! http://www.uipzqhao.cn Don't delay your pleasure: our incredible watch collection awaits you at Diam0nd Reps, so come visit us now! From aaaa@ol.com Tue Apr 21 05:57:44 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D925E3A6A04; Tue, 21 Apr 2009 05:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -42.146 X-Spam-Level: X-Spam-Status: No, score=-42.146 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_DSN=1.495, HELO_EQ_AU=0.377, J_CHICKENPOX_42=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tw4qR5+xCL8T; Tue, 21 Apr 2009 05:57:44 -0700 (PDT) Received: from midcoast.com.au (cm124.gamma47.maxonline.com.sg [202.156.47.124]) by core3.amsl.com (Postfix) with ESMTP id 449CC3A6948; Tue, 21 Apr 2009 05:57:42 -0700 (PDT) Message-ID: Date: Tue, 21 Apr 2009 08:59:00 -0500 From: "Kemp Susanne" TO: <"send-archive@megatron.ietf.org, trade-archive@megatron.ietf.org, provreg-archive@megatron.ietf.org, sctp-impl-archive@megatron.ietf.org, ldapbis-archive@megatron.ietf.org, snmpconf-archive@megatron.ietf.org, web-archive"@megatron.ietf.org> Subject: Watches made to impress Content-Type: text/plain; Content-Transfer-Encoding: 7Bit There are things in life that seem unattainable. Owning a fine watch doesn't have to be one of them. http://www.uiokyyqo.cn Take advantage of Diam0nd Reps tremendous specials, and get yourself a superb designer watch imitation for just a couple of hundred bucks. Plus an extra 15 percent discount when you get two time pieces in the same purchase! http://www.uiokyyqo.cn Check out our extensive inventory and enjoy the fastest shipping available online! See you at Diam0nd Reps! From jmsyweu@allianceweb.co.uk Tue Apr 21 11:59:03 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A99028C22D for ; Tue, 21 Apr 2009 11:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.796 X-Spam-Level: X-Spam-Status: No, score=-14.796 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCinSSgRapOa for ; Tue, 21 Apr 2009 11:58:57 -0700 (PDT) Received: from al-futtaim.ae (unknown [189.29.131.70]) by core3.amsl.com (Postfix) with SMTP id 0116B28C2BD for ; Tue, 21 Apr 2009 11:58:54 -0700 (PDT) To: " Date: Tue, 21 Apr 2009 11:58:54 -0700 (PDT)
Men's Health wirzpBuild Maximum MUSCLE, STRENGTH, and POWER!
Try It FREE for 21 Days! ORDER NOW! Plus, get 2 FREE Bonus Gifts!
Dear provreg-archive

Men's Health recommends


FREE gifts reserved for you: provreg-archive@ietf.org
If you would prefer not to receive future information about special offers from Men's Health,
you may Unsubscribe.


Customer Service Department, 33 East Minor Street, Emmaus, PA 18098


Copyright, Men's Health
From pactolus@newsguy.com Wed Apr 22 05:15:21 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 632813A67B5; Wed, 22 Apr 2009 05:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.146 X-Spam-Level: X-Spam-Status: No, score=-14.146 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, J_CHICKENPOX_42=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njBhRUJMO4xq; Wed, 22 Apr 2009 05:15:20 -0700 (PDT) Received: from 235-1-133-95.pool.ukrtel.net (235-1-133-95.pool.ukrtel.net [95.133.1.235]) by core3.amsl.com (Postfix) with SMTP id D94F23A67A5; Wed, 22 Apr 2009 05:15:16 -0700 (PDT) From: "Haley Eastman" To: <"pim-bounces@ietf.org, pim-request@ietf.org, pint-archive@ietf.org, pmol@ietf.org, pppext@ietf.org, pppext-request@ietf.org, proceedings@ietf.org, provreg-archive"@ietf.org> Subject: Cartier reps better than originals Date: Wed, 22 Apr 2009 08:16:35 -0500 Message-ID: <3203zae914291FWWWpim-bounces@ietf.org> Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Loving yourself is the first step in loving life. And what better way to do it, than by getting yourself a fine designer watch? http://www.gekodatag.cn The watch of your dreams doesn't have to be an overpriced piece of machinery. Nowadays you can get the same functionality and distinctive looks from the next best thing. Visit Diam0nd Reps and choose from hundreds of gorgeous models at less than ten percent the price of an original. http://www.gekodatag.cn Get ready to feel like a kid in a candy store when you see our incredible collection of fine reproduction timepieces at Diam0nd Reps! Come on, get started now! From a.hoellwart@acsi-jv.com Wed Apr 22 06:10:21 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D403F3A6F2E; Wed, 22 Apr 2009 06:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -30.573 X-Spam-Level: X-Spam-Status: No, score=-30.573 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, J_CHICKENPOX_42=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SORTED_RECIPS=1.125, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CviJQUXGvBNa; Wed, 22 Apr 2009 06:10:21 -0700 (PDT) Received: from ppp-58-9-208-53.revip2.asianet.co.th (ppp-58-9-208-53.revip2.asianet.co.th [58.9.208.53]) by core3.amsl.com (Postfix) with SMTP id 1968728C3F1; Wed, 22 Apr 2009 06:10:13 -0700 (PDT) From: "Ernie Blackman" To: <"multi6-archive@megatron.ietf.org, openpgp-archive@megatron.ietf.org, opes-archive@megatron.ietf.org, printmib-archive@megatron.ietf.org, provreg-archive@megatron.ietf.org, sctp-impl-archive@megatron.ietf.org, send-archive@megatron.ietf.org, smime-archive"@megatron.ietf.org> Subject: Why rep watches are better Date: Wed, 22 Apr 2009 09:11:20 -0500 Message-ID: <2790dro646471YINEmulti6-archive@megatron.ietf.org> Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Why waste your hard-earned money on an expensive watch when you can have the next best thing for a tenth of its price? http://www.iolvpvee.cn How does 90 percent off sound? Great, of course! And greatness is what awaits you at Diam0nd Reps, the preferred online store where you will find the finest watch imitations for exactly that: 90% off! http://www.iolvpvee.cn So, what are you waiting for? Get that unique timepiece today at Diam0nd Reps! From owner-ietf-provreg@cafax.se Wed Apr 22 10:36:31 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB83C3A69AB for ; Wed, 22 Apr 2009 10:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raMGie0QjGGu for ; Wed, 22 Apr 2009 10:36:30 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 46F9A3A6940 for ; Wed, 22 Apr 2009 10:36:29 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029FDC82@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <046F43A8D79C794FA4733814869CDF07029FDA56@dul1wnexmb01.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Text Proposal for the TLS Usage Profile Thread-Index: AcnBtlJ3wuYfcq9nTMqUS2v8Sbs8KwBuMXWA References: <046F43A8D79C794FA4733814869CDF07029FDA56@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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: ietf-provreg@cafax.se > 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 ietf-provreg-request@cafax.se From monique.castel@afnor.fr Wed Apr 22 21:25:36 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05F043A69BD for ; Wed, 22 Apr 2009 21:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.619 X-Spam-Level: X-Spam-Status: No, score=-10.619 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcUZTL3VoawR for ; Wed, 22 Apr 2009 21:25:30 -0700 (PDT) Received: from 7778.com (unknown [59.162.182.34]) by core3.amsl.com (Postfix) with SMTP id 623AD3A6A45 for ; Wed, 22 Apr 2009 21:25:26 -0700 (PDT) To: " Date: Wed, 22 Apr 2009 21:25:26 -0700 (PDT)
Men's Health wirzpBuild Maximum MUSCLE, STRENGTH, and POWER!
Try It FREE for 21 Days! ORDER NOW! Plus, get 2 FREE Bonus Gifts!
Dear provreg-archive

Men's Health recommends


FREE gifts reserved for you: provreg-archive@ietf.org
If you would prefer not to receive future information about special offers from Men's Health,
you may Unsubscribe.


Customer Service Department, 33 East Minor Street, Emmaus, PA 18098


Copyright, Men's Health
From owner-ietf-provreg@cafax.se Thu Apr 23 05:37:55 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0D253A72DB for ; Thu, 23 Apr 2009 05:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATI-mO8xPegJ for ; Thu, 23 Apr 2009 05:37:55 -0700 (PDT) Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by core3.amsl.com (Postfix) with ESMTP id 2841D3A6BC6 for ; Thu, 23 Apr 2009 05:37:25 -0700 (PDT) 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029FDD0D@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <49E5D9FA.5030107@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Standards Track Advancement Request for EPP RFCs Thread-Index: Acm9yfhyB5hfNV7HSw2hjJK2mRfanAGREiFg References: <046F43A8D79C794FA4733814869CDF07029A1123@dul1wnexmb01.vcorp.ad.vrsn.com> <49DD3B2A.5060803@isode.com> <046F43A8D79C794FA4733814869CDF07029FD4A4@dul1wnexmb01.vcorp.ad.vrsn.com> <49E06372.6090205@isode.com> <046F43A8D79C794FA4733814869CDF07029FD624@dul1wnexmb01.vcorp.ad.vrsn.com> <49E58C49.4060907@isode.com> <046F43A8D79C794FA4733814869CDF07029FD7FA@dul1wnexmb01.vcorp.ad.vrsn.com> <49E5D530.3080308@isode.com> <49E5D6CE.80506@isode.com> <046F43A8D79C794FA4733814869CDF07029FD805@dul1wnexmb01.vcorp.ad.vrsn.com> <49E5D8D5.9020501@isode.com> <49E5D9FA.5030107@isode.com> 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: owner-ietf-provreg@cafax.se 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 ietf-provreg-request@cafax.se From aa051981961@aermacchi.it Thu Apr 23 07:49:45 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5E8B3A6907; Thu, 23 Apr 2009 07:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -43.513 X-Spam-Level: X-Spam-Status: No, score=-43.513 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, J_CHICKENPOX_42=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_SPEC_ROLEX_NOV5A=1.062, SUBJECT_FUZZY_TION=0.156, URIBL_BLACK=20, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1OQn+fEOhUh; Thu, 23 Apr 2009 07:49:44 -0700 (PDT) Received: from ppp-124-121-229-159.revip2.asianet.co.th (ppp-124-121-229-159.revip2.asianet.co.th [124.121.229.159]) by core3.amsl.com (Postfix) with SMTP id 4B1433A71C8; Thu, 23 Apr 2009 07:49:35 -0700 (PDT) From: "Audra Combs" To: <"proceedings@ietf.org, provreg-archive@ietf.org, psamp@ietf.org, psamp-request@ietf.org, pwe3@ietf.org, pwe3-bounces@ietf.org, pwe3-chairs@ietf.org, pwe3-request"@ietf.org> Subject: Inexpensive Louis Vuitton bags Date: Thu, 23 Apr 2009 10:50:56 -0500 Message-ID: <4455qao361890BDAGproceedings@ietf.org> Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Money is tight, times are hard. Christmas is over. Time to get a new Watch! http://www.uisxbalo.cn So, come visit Diam0nd Reps, the famous watch-portal where thousands of satisfied customers have already found that superb imitation time piece for just a few hundred dollars. http://www.uisxbalo.cn So, what are you waiting for? Get that unique timepiece today at Diam0nd Reps! From witch@aster.pl Thu Apr 23 08:35:44 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 727F228C2A2; Thu, 23 Apr 2009 08:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -24.848 X-Spam-Level: X-Spam-Status: No, score=-24.848 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DYNAMIC=1.144, HELO_EQ_TW=1.335, J_CHICKENPOX_42=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuGlSNokAtcU; Thu, 23 Apr 2009 08:35:43 -0700 (PDT) Received: from 123-194-143-213.dynamic.kbronet.com.tw (123-194-143-213.dynamic.kbronet.com.tw [123.194.143.213]) by core3.amsl.com (Postfix) with SMTP id EA1D73A6EC1; Thu, 23 Apr 2009 08:35:39 -0700 (PDT) From: "Wilson Villegas" To: <"pmol@ietf.org, pppext@ietf.org, pppext-request@ietf.org, proceedings@ietf.org, provreg-archive@ietf.org, psamp@ietf.org, psamp-request"@ietf.org> Subject: Vacheron Constantin watch models from 2009! Date: Thu, 23 Apr 2009 11:36:59 -0500 Message-ID: <3411vqs360124NBPTpmol@ietf.org> Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Loving yourself is the first step in loving life. And what better way to do it, than by getting yourself a fine designer watch? http://www.uikyivyo.cn The watch of your dreams doesn't have to be an overpriced piece of machinery. Nowadays you can get the same functionality and distinctive looks from the next best thing. Visit Diam0nd Reps and choose from hundreds of gorgeous models at less than ten percent the price of an original. http://www.uikyivyo.cn Don't believe me? Click here to enter Diam0nd Reps right now, and see it with your very own eyes! From mmaher@aacps.org Sat Apr 25 12:38:25 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 265F73A6822 for ; Sat, 25 Apr 2009 12:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.621 X-Spam-Level: X-Spam-Status: No, score=-19.621 tagged_above=-999 required=5 tests=[APOSTROPHE_FROM=0.001, BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B624NzQWy9iD for ; Sat, 25 Apr 2009 12:38:24 -0700 (PDT) Received: from akebono-brake.co.jp (unknown [213.201.70.241]) by core3.amsl.com (Postfix) with SMTP id C76D13A69B5 for ; Sat, 25 Apr 2009 12:38:19 -0700 (PDT) To: " Date: Sat, 25 Apr 2009 12:38:19 -0700 (PDT)

Read more
Copyright
Subscribe to Men's Health Today!
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Department, 33 East Minor Street, Emmaus, PA 18098
From jbarrettdd@amcautomation.com Sun Apr 26 00:32:51 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B10FB3A6E97 for ; Sun, 26 Apr 2009 00:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.103 X-Spam-Level: X-Spam-Status: No, score=-4.103 tagged_above=-999 required=5 tests=[APOSTROPHE_FROM=0.001, BAYES_99=3.5, HELO_DYNAMIC_HCC=4.295, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FHwUaIhZepn for ; Sun, 26 Apr 2009 00:32:50 -0700 (PDT) Received: from cpc2-oxfd2-0-0-cust503.oxfd.cable.ntl.com (cpc2-oxfd2-0-0-cust503.oxfd.cable.ntl.com [82.10.101.248]) by core3.amsl.com (Postfix) with SMTP id AC30F3A6DBB for ; Sun, 26 Apr 2009 00:32:48 -0700 (PDT) To: " Date: Sun, 26 Apr 2009 00:32:48 -0700 (PDT)

Read more
Copyright
Subscribe to Men's Health Today!
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Department, 33 East Minor Street, Emmaus, PA 18098
From mistercs@allenhurst-nj.com Sun Apr 26 10:45:15 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D36893A6EF9 for ; Sun, 26 Apr 2009 10:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.032 X-Spam-Level: X-Spam-Status: No, score=-12.032 tagged_above=-999 required=5 tests=[APOSTROPHE_FROM=0.001, BAYES_99=3.5, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQoGE5VLT1BX for ; Sun, 26 Apr 2009 10:44:57 -0700 (PDT) Received: from asx89.neoplus.adsl.tpnet.pl (asx89.neoplus.adsl.tpnet.pl [83.26.235.89]) by core3.amsl.com (Postfix) with SMTP id D17103A6E93 for ; Sun, 26 Apr 2009 10:44:47 -0700 (PDT) To: " Date: Sun, 26 Apr 2009 10:44:47 -0700 (PDT)

Read more
Copyright
Subscribe to Men's Health Today!
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Department, 33 East Minor Street, Emmaus, PA 18098
From lcuttingl@alssnowmobile.com Mon Apr 27 05:03:02 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDBFD3A6C9B for ; Mon, 27 Apr 2009 05:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.597 X-Spam-Level: X-Spam-Status: No, score=-12.597 tagged_above=-999 required=5 tests=[APOSTROPHE_FROM=0.001, BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_TW=1.335, HELO_MISMATCH_TW=0.994, HTML_IMAGE_ONLY_16=1.526, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X03JbPU31piq for ; Mon, 27 Apr 2009 05:03:02 -0700 (PDT) Received: from host161-62-static.91-82-b.business.telecomitalia.it (host161-62-static.91-82-b.business.telecomitalia.it [82.91.62.161]) by core3.amsl.com (Postfix) with SMTP id 056A73A6ECC for ; Mon, 27 Apr 2009 05:02:58 -0700 (PDT) To: " Date: Mon, 27 Apr 2009 05:02:58 -0700 (PDT)

Read more
Copyright
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Department, 33 East Minor Street, Emmaus, PA 18098
From lrbdjsp@adbag.de Tue Apr 28 23:44:40 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC8013A6D86 for ; Tue, 28 Apr 2009 23:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7A0TzNGeM7U for ; Tue, 28 Apr 2009 23:44:33 -0700 (PDT) Received: from 173-105-49-208.pools.spcsdns.net (173-105-49-208.pools.spcsdns.net [173.105.49.208]) by core3.amsl.com (Postfix) with SMTP id 8F7DA3A688B for ; Tue, 28 Apr 2009 23:44:30 -0700 (PDT) To: provreg-archive@ietf.org Subject: RE: Q&A Doctor Eloy From: provreg-archive@ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090429064431.8F7DA3A688B@core3.amsl.com> Date: Tue, 28 Apr 2009 23:44:30 -0700 (PDT)
Tell a friend · Download latest version See this email as a webpage

Hello!

Shipped Privately And Discreetly To Your Door!
See this email as a webpage
  We want to put a great big grin on your face in 2009. You'll be to rejoice all year.  

Unsubscribe · Lost Password · Account Settings · Help · Terms of Service · Privacy

Ottho Heldringstraat 1, 63648 AZ Amsterdam, The Netherlands
From joo@allengooch.com Wed Apr 29 17:26:50 2009 Return-Path: X-Original-To: ietfarch-provreg-archive@core3.amsl.com Delivered-To: ietfarch-provreg-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A801D28C0E5 for ; Wed, 29 Apr 2009 17:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -60.237 X-Spam-Level: X-Spam-Status: No, score=-60.237 tagged_above=-999 required=5 tests=[APOSTROPHE_FROM=0.001, BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_BLACK=20, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lp-ADj5-aXNo for ; Wed, 29 Apr 2009 17:26:43 -0700 (PDT) Received: from advantagewebcms.com (unknown [94.29.111.152]) by core3.amsl.com (Postfix) with SMTP id AB9D53A7186 for ; Wed, 29 Apr 2009 17:25:59 -0700 (PDT) To: " Date: Wed, 29 Apr 2009 17:25:59 -0700 (PDT)

Read more
Copyright
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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029FDD0D@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <49E5D9FA.5030107@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Standards Track Advancement Request for EPP RFCs Thread-Index: Acm9yfhyB5hfNV7HSw2hjJK2mRfanAGREiFg References: <046F43A8D79C794FA4733814869CDF07029A1123@dul1wnexmb01.vcorp.ad.vrsn.com> <49DD3B2A.5060803@isode.com> <046F43A8D79C794FA4733814869CDF07029FD4A4@dul1wnexmb01.vcorp.ad.vrsn.com> <49E06372.6090205@isode.com> <046F43A8D79C794FA4733814869CDF07029FD624@dul1wnexmb01.vcorp.ad.vrsn.com> <49E58C49.4060907@isode.com> <046F43A8D79C794FA4733814869CDF07029FD7FA@dul1wnexmb01.vcorp.ad.vrsn.com> <49E5D530.3080308@isode.com> <49E5D6CE.80506@isode.com> <046F43A8D79C794FA4733814869CDF07029FD805@dul1wnexmb01.vcorp.ad.vrsn.com> <49E5D8D5.9020501@isode.com> <49E5D9FA.5030107@isode.com> 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: owner-ietf-provreg@cafax.se 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 ietf-provreg-request@cafax.se 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029FDC82@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <046F43A8D79C794FA4733814869CDF07029FDA56@dul1wnexmb01.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Text Proposal for the TLS Usage Profile Thread-Index: AcnBtlJ3wuYfcq9nTMqUS2v8Sbs8KwBuMXWA References: <046F43A8D79C794FA4733814869CDF07029FDA56@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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: ietf-provreg@cafax.se > 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 ietf-provreg-request@cafax.se 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029FDA56@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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 ietf-provreg-request@cafax.se 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 owner-ietf-provreg@cafax.se 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 jaap@bartok.nlnetlabs.nl) Message-Id: <200904152145.n3FLjAkQ034555@bartok.nlnetlabs.nl> To: ietf-provreg@cafax.se 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: owner-ietf-provreg@cafax.se 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 ietf-proveg-request@cafax.se 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 owner-ietf-provreg@cafax.se 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 jaap@bartok.nlnetlabs.nl) Message-Id: <200904151938.n3FJcg8F095212@bartok.nlnetlabs.nl> To: Edward Lewis cc: ietf-provreg@cafax.se 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: owner-ietf-provreg@cafax.se 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029FD862@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se Precedence: bulk I believe the guy you're looking for is Lars-Johan Liman: http://www.cafax.se/~liman/ -Scott- > -----Original Message----- > From: owner-ietf-provreg@cafax.se > [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Edward Lewis > Sent: Wednesday, April 15, 2009 2:51 PM > To: ietf-provreg@cafax.se > Cc: ed.lewis@neustar.biz > 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 owner-ietf-provreg@cafax.se 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 Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Wed, 15 Apr 2009 14:50:41 -0400 To: ietf-provreg@cafax.se From: Edward Lewis Subject: [ietf-provreg] who's running the list? Cc: ed.lewis@Neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-ietf-provreg@cafax.se 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029FD808@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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 jgould@verisign.com 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:alexey.melnikov@isode.com] 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:alexey.melnikov@isode.com] >>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 Re: [ietf-provreg] FW: Standards Track Advancement Request for EPP R= FCs 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
jgould@verisign.com
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; <shollenbeck@verisign.com>= ;
Date: Wed, 15 Apr 2009 09:00:22 -0400
To: EPP Provreg <ietf-provreg@caf= ax.se>
Cc: Alexey Melnikov <alexey.m= elnikov@isode.com>
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= exey.melnikov@isode.com]
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:alexey.melnikov@isode.com]
>>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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029FD808@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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:alexey.melnikov@isode.com] 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:alexey.melnikov@isode.com] >>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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029FD729@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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 jgould@verisign.com 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 > jgould@verisign.com > 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
jgould@verisign.com
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; <shollenbeck@verisign.com>= ;
Date: Tue, 14 Apr 2009 07:14:58 -0400
To: James Gould <jgould@verisign.co= 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
jgould@verisign.com
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= " <shollenbeck@verisign.com&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 owner-ietf-provreg@cafax.se 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 provreg@contact.dotandco.com using -f Date: Tue, 14 Apr 2009 15:23:30 +0200 From: Patrick Mevzek To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] AD Review Comments: draft-hollenbeck-rfc4934bis-00 Message-ID: <20090414132330.GB6802@home.patoche.org> References: <046F43A8D79C794FA4733814869CDF07029FD625@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <046F43A8D79C794FA4733814869CDF07029FD625@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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 owner-ietf-provreg@cafax.se 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 provreg@contact.dotandco.com 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: <20090414131105.GA6802@home.patoche.org> References: <046F43A8D79C794FA4733814869CDF07029FD625@dul1wnexmb01.vcorp.ad.vrsn.com> <046F43A8D79C794FA4733814869CDF07029FD729@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <046F43A8D79C794FA4733814869CDF07029FD729@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029FD729@dul1wnexmb01.vcorp.ad.vrsn.com> 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: <046F43A8D79C794FA4733814869CDF07029FD625@dul1wnexmb01.vcorp.ad.vrsn.com> From: "Hollenbeck, Scott" To: "Gould, James" , "EPP Provreg" X-OriginalArrivalTime: 14 Apr 2009 11:14:59.0229 (UTC) FILETIME=[3F9F6CD0:01C9BCF2] Sender: owner-ietf-provreg@cafax.se 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 jgould@verisign.com 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
jgould@verisign.com
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" <shollenbeck@verisign.com>
= Date:=20 Mon, 13 Apr 2009 08:37:25 -0400
To: EPP Provreg <ietf-provreg@cafax.se>
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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029FD625@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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 jgould@verisign.com 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
jgould@verisign.com
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; <shollenbeck@verisign.com>= ;
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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029FD625@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029A107B@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, April 06, 2009 12:45 PM To: i-d-announce@ietf.org 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029A1060@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, April 06, 2009 11:00 AM To: i-d-announce@ietf.org 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029A105F@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, April 06, 2009 11:00 AM To: i-d-announce@ietf.org 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029A105E@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, April 06, 2009 11:00 AM To: i-d-announce@ietf.org 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 owner-ietf-provreg@cafax.se 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: <8803B199-A11C-4CCB-A104-61E041143A65@cisco.com> 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=paf@cisco.com; 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=paf@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-ietf-provreg@cafax.se 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029A0FC7@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, April 03, 2009 2:45 PM To: i-d-announce@ietf.org 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 owner-ietf-provreg@cafax.se 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: <33002F21-8354-4E8F-A23A-DC35F58E5CC4@cisco.com> 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: owner-ietf-provreg@cafax.se 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 jgould@verisign.com 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:

  1. 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.  
  2. 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.  
  3. 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
jgould@verisign.com
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 <paf@cisco.com>
> Date: Thu, 2 Apr 2009 14:31:52 -0400
> To: James Gould <jgould@verisign.com<= /a>>
> Cc: "Hollenbeck, Scott" <shollenbeck@verisign.com>, <Chri= s.Newman@Sun.COM>,
> EPP Provreg <ietf-provreg@cafax.se<= /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 owner-ietf-provreg@cafax.se 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 brunner@nic-naa.net) Message-ID: <49D53EC2.1010606@nic-naa.net> 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" , Chris.Newman@Sun.COM, EPP Provreg Subject: Re: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs References: <33002F21-8354-4E8F-A23A-DC35F58E5CC4@cisco.com> In-Reply-To: <33002F21-8354-4E8F-A23A-DC35F58E5CC4@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se 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 owner-ietf-provreg@cafax.se 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: <33002F21-8354-4E8F-A23A-DC35F58E5CC4@cisco.com> 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=paf@cisco.com; 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=paf@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-ietf-provreg@cafax.se 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 owner-ietf-provreg@cafax.se 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: owner-ietf-provreg@cafax.se 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 jgould@verisign.com 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
jgould@verisign.com
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 <paf@cisco.com>
> Date: Thu, 2 Apr 2009 12:55:08 -0400
> To: James Gould <jgould@verisign.com<= /a>>
> Cc: "Hollenbeck, Scott" <shollenbeck@verisign.com>, <Chri= s.Newman@Sun.COM>,
> EPP Provreg <ietf-provreg@cafax.se<= /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 owner-ietf-provreg@cafax.se 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: <49F7F63E-E756-4EF5-BAEF-8467810D8217@cisco.com> 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: <046F43A8D79C794FA4733814869CDF07026523E3@dul1wnexmb01.vcorp.ad.vrsn.com> <046F43A8D79C794FA4733814869CDF07029A0E33@dul1wnexmb01.vcorp.ad.vrsn.com> <2265CB25-98CE-4C4C-9795-682E3200BBC2@cisco.com> <046F43A8D79C794FA4733814869CDF07029A0E3C@dul1wnexmb01.vcorp.ad.vrsn.com> 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=paf@cisco.com; 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=paf@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Sender: owner-ietf-provreg@cafax.se 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 owner-ietf-provreg@cafax.se 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=paf@cisco.com; 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=paf@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-ietf-provreg@cafax.se 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 owner-ietf-provreg@cafax.se 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 Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <046F43A8D79C794FA4733814869CDF07029A0E3C@dul1wnexmb01.vcorp.ad.vrsn.com> References: <046F43A8D79C794FA4733814869CDF07026523E3@dul1wnexmb01.vcorp.ad.vrsn.com> <046F43A8D79C794FA4733814869CDF07029A0E33@dul1wnexmb01.vcorp.ad.vrsn.com> <2265CB25-98CE-4C4C-9795-682E3200BBC2@cisco.com> <046F43A8D79C794FA4733814869CDF07029A0E3C@dul1wnexmb01.vcorp.ad.vrsn.com> 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: ed.lewis@Neustar.biz 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: owner-ietf-provreg@cafax.se 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:paf@cisco.com] >> Sent: Thursday, April 02, 2009 8:49 AM >> To: Hollenbeck, Scott >> Cc: Chris.Newman@Sun.COM; ietf-provreg@cafax.se >> 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: Chris.Newman@Sun.COM [mailto:Chris.Newman@Sun.COM] >> >> Sent: Tuesday, December 16, 2008 12:08 AM >> >> To: Hollenbeck, Scott; lisa@osafoundation.org >> >> Cc: ietf-provreg@cafax.se; iesg@ietf.org >> >> 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 owner-ietf-provreg@cafax.se 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: <2265CB25-98CE-4C4C-9795-682E3200BBC2@cisco.com> 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: owner-ietf-provreg@cafax.se 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 jgould@verisign.com 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: Chris.Newman@Sun.COM [mailto:Chris.Newman@Sun.COM] >>> Sent: Tuesday, December 16, 2008 12:08 AM >>> To: Hollenbeck, Scott; lisa@osafoundation.org >>> Cc: ietf-provreg@cafax.se; iesg@ietf.org >>> 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:

  1. External hosts per Registrar, where an association f= rom domains to external hosts of another client (Registrar) is not allowed.
  2. 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
jgould@verisign.com
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 <paf@cisco.com>
> Date: Thu, 2 Apr 2009 08:49:06 -0400
> To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
> Cc: <Chris.Newman@Sun.COM>, E= PP Provreg <ietf-provreg@cafax.se>=
> 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: Chris.Newman@Sun.COM = [mailto:Chris.Newman@Sun.COM]
>>> Sent: Tuesday, December 16, 2008 12:08 AM
>>> To: Hollenbeck, Scott; lisa@o= safoundation.org
>>> Cc: ietf-provreg@cafax.se;= iesg@ietf.org
>>> 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;
>>> <shollenbeck@verisign.co= 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029A0E3C@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <2265CB25-98CE-4C4C-9795-682E3200BBC2@cisco.com> 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: <046F43A8D79C794FA4733814869CDF07026523E3@dul1wnexmb01.vcorp.ad.vrsn.com> <046F43A8D79C794FA4733814869CDF07029A0E33@dul1wnexmb01.vcorp.ad.vrsn.com> <2265CB25-98CE-4C4C-9795-682E3200BBC2@cisco.com> 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: owner-ietf-provreg@cafax.se 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:paf@cisco.com] > Sent: Thursday, April 02, 2009 8:49 AM > To: Hollenbeck, Scott > Cc: Chris.Newman@Sun.COM; ietf-provreg@cafax.se > 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: Chris.Newman@Sun.COM [mailto:Chris.Newman@Sun.COM] > >> Sent: Tuesday, December 16, 2008 12:08 AM > >> To: Hollenbeck, Scott; lisa@osafoundation.org > >> Cc: ietf-provreg@cafax.se; iesg@ietf.org > >> 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 owner-ietf-provreg@cafax.se 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 brunner@nic-naa.net) Message-ID: <49D4BE9C.1020800@nic-naa.net> 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" , Chris.Newman@Sun.COM, ietf-provreg@cafax.se Subject: Re: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs References: <046F43A8D79C794FA4733814869CDF07026523E3@dul1wnexmb01.vcorp.ad.vrsn.com> <046F43A8D79C794FA4733814869CDF07029A0E33@dul1wnexmb01.vcorp.ad.vrsn.com> <2265CB25-98CE-4C4C-9795-682E3200BBC2@cisco.com> In-Reply-To: <2265CB25-98CE-4C4C-9795-682E3200BBC2@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-provreg@cafax.se 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: Chris.Newman@Sun.COM [mailto:Chris.Newman@Sun.COM] >>> Sent: Tuesday, December 16, 2008 12:08 AM >>> To: Hollenbeck, Scott; lisa@osafoundation.org >>> Cc: ietf-provreg@cafax.se; iesg@ietf.org >>> 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 owner-ietf-provreg@cafax.se 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: <2265CB25-98CE-4C4C-9795-682E3200BBC2@cisco.com> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Hollenbeck, Scott" In-Reply-To: <046F43A8D79C794FA4733814869CDF07029A0E33@dul1wnexmb01.vcorp.ad.vrsn.com> 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: <046F43A8D79C794FA4733814869CDF07026523E3@dul1wnexmb01.vcorp.ad.vrsn.com> <046F43A8D79C794FA4733814869CDF07029A0E33@dul1wnexmb01.vcorp.ad.vrsn.com> 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=paf@cisco.com; 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=paf@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-ietf-provreg@cafax.se 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: Chris.Newman@Sun.COM [mailto:Chris.Newman@Sun.COM] >> Sent: Tuesday, December 16, 2008 12:08 AM >> To: Hollenbeck, Scott; lisa@osafoundation.org >> Cc: ietf-provreg@cafax.se; iesg@ietf.org >> 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 owner-ietf-provreg@cafax.se 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: <046F43A8D79C794FA4733814869CDF07029A0E33@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Standards Track Advancement Request for EPP RFCs Thread-Index: AclfPEmLxzGQCTh9QIydcPASccvEChUR8ZUw References: <046F43A8D79C794FA4733814869CDF07026523E3@dul1wnexmb01.vcorp.ad.vrsn.com> 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: owner-ietf-provreg@cafax.se 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: Chris.Newman@Sun.COM [mailto:Chris.Newman@Sun.COM] > Sent: Tuesday, December 16, 2008 12:08 AM > To: Hollenbeck, Scott; lisa@osafoundation.org > Cc: ietf-provreg@cafax.se; iesg@ietf.org > 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 > >