RE: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

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
> >>
> >>
> >
> 
>