To:
<ietf-provreg@cafax.se>
Cc:
ed.lewis@Neustar.biz
From:
Edward Lewis <Ed.Lewis@Neustar.biz>
Date:
Thu, 2 Apr 2009 10:27:17 -0400
In-Reply-To:
<046F43A8D79C794FA4733814869CDF07029A0E3C@dul1wnexmb01.vcorp.ad.vrsn.com>
Sender:
owner-ietf-provreg@cafax.se
Subject:
RFC 4310 RE: [ietf-provreg] RE: Standards Track AdvancementRequest for EPP RFCs
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 <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 >> >> >> >> >> > >> >> -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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.