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

[Edward Lewis <[e-mail]>]

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:[e-mail]]
>>  Sent: Thursday, April 02, 2009 8:49 AM
>>  To: Hollenbeck, Scott
>>  Cc: [e-mail]; [e-mail]
>>  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: [e-mail] [mailto:[e-mail]]
>>  >> Sent: Tuesday, December 16, 2008 12:08 AM
>>  >> To: Hollenbeck, Scott; [e-mail]
>>  >> Cc: [e-mail]; [e-mail]
>>  >> Subject: RE: Standards Track Advancement Request for EPP RFCs
>>  >>
>>  >> Two questions I missed:
>>  >>
>>  >> --On October 17, 2008 8:28:31 -0400 "Hollenbeck, Scott"
>>  >> <[e-mail]> 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 [phone]

Getting everything you want is easy if you don't want much.