RE: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs
"Hollenbeck, Scott" <shollenbeck@verisign.com> Thu, 02 April 2009 13:48 UTC
Return-Path: <owner-ietf-provreg@cafax.se>
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 <ietfarch-provreg-archive@core3.amsl.com>; 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 <ietfarch-provreg-archive@core3.amsl.com>; 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 <provreg-archive@ietf.org>; 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 <ietf-provreg-outgoing@nic.cafax.se>; 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 <ietf-provreg@cafax.se>; 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, 02 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> <F9BDE7EE452DF0E9076C4D1A@446E7922C82D299DB29D899F> <046F43A8D79C794FA4733814869CDF07029A0E33@dul1wnexmb01.vcorp.ad.vrsn.com> <2265CB25-98CE-4C4C-9795-682E3200BBC2@cisco.com>
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: Patrik Fältström <paf@cisco.com>
Cc: Chris.Newman@Sun.COM, ietf-provreg@cafax.se
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 <secDNS:add> element 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> element 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 <secDNS:rem> 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" > >> <shollenbeck@verisign.com> 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: > >> <http://tools.ietf.org/html/draft-ietf-syslog-transport-tls> > >> > >> - Chris > >> > >> > > > >
- [ietf-provreg] Standards Track Advancement Reques… Hollenbeck, Scott
- [ietf-provreg] RE: Standards Track Advancement Re… Hollenbeck, Scott
- [ietf-provreg] RE: Standards Track Advancement Re… Hollenbeck, Scott
- [ietf-provreg] RE: Standards Track Advancement Re… Hollenbeck, Scott
- [ietf-provreg] RE: Standards Track Advancement Re… Hollenbeck, Scott
- [ietf-provreg] RE: Standards Track Advancement Re… Hollenbeck, Scott
- [ietf-provreg] RE: Standards Track Advancement Re… Edward Lewis
- Re: [ietf-provreg] RE: Standards Track Advancemen… Jaap Akkerhuis
- Re: [ietf-provreg] RE: Standards Track Advancemen… Patrick Mevzek
- Re: [ietf-provreg] RE: Standards Track Advancemen… Patrick Mevzek
- [ietf-provreg] Re: Standards Track Advancement Re… Stephane Bortzmeyer
- [ietf-provreg] RE: Standards Track Advancement Re… Hollenbeck, Scott
- Re: [ietf-provreg] RE: Standards Track Advancemen… Patrik Fältström
- Re: [ietf-provreg] RE: Standards Track Advancemen… Eric Brunner-Williams
- RE: [ietf-provreg] RE: Standards Track Advancemen… Hollenbeck, Scott
- Re: [ietf-provreg] RE: Standards Track Advancemen… James Gould
- RFC 4310 RE: [ietf-provreg] RE: Standards Track A… Edward Lewis
- Re: RFC 4310 RE: [ietf-provreg] RE: Standards Tra… Patrik Fältström
- Re: [ietf-provreg] RE: Standards Track Advancemen… Patrik Fältström
- Re: [ietf-provreg] RE: Standards Track Advancemen… James Gould
- Re: [ietf-provreg] RE: Standards Track Advancemen… Patrik Fältström
- Re: [ietf-provreg] RE: Standards Track Advancemen… Eric Brunner-Williams
- Re: [ietf-provreg] RE: Standards Track Advancemen… James Gould
- Re: [ietf-provreg] RE: Standards Track Advancemen… Patrik Fältström
- [ietf-provreg] FW: Standards Track Advancement Re… Hollenbeck, Scott
- Re: [ietf-provreg] FW: Standards Track Advancemen… James Gould
- [ietf-provreg] RE: Standards Track Advancement Re… Hollenbeck, Scott