Re: [ietf-provreg] RE: Standards Track Advancement Request for EPPRFCs

[Eric Brunner-Williams <brunner@nic-naa.net>]

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