Re: [ietf-provreg] 4310-bis progress

[James Gould <jgould@verisign.com>]

Title: Re: [ietf-provreg] 4310-bis progress

Ray,

Excellent question.  I sent an update to the AD almost a week ago and I haven’t received a response yet.  I’m working from the following assumptions related to the discussed items on the list:

1. schema versions – 4310-bis will use a new URI secDNS-1.1.  By changing the URI is breaks backward compatibility, but this will allow us to address other issues more cleanly.  
2. maxSigLife – The maxSigLife will be moved out of the dsData and directly under secDNS:create, secDNS:update, and secDNS:infData since it applies across all of the DS for a domain.
3. Ulrich’s request to remove the backward compatibility inconsistent or undesirable features.  These include removing support of secDNS:rem with secDNS:keyTag and to change secDNS:chg to work as a true change instead of a replace or to remove secDNS:chg altogether.  I’m in favor of addressing this request after we broke backward compatibility with #1, where removing support for secDNS:rem with secDNS:keyTag and removing support for secDNS:chg is straightforward.  Since maxSigLife was moved outside the the dsData in #2, use of secDNS:chg for DS is not needed.  The only purpose for secDNS:chg is if there is the need to change an attribute in secDNS:dsData or secDNS:keyData based on #4 below.
4. Eduardo’s request for an “active” flag based on asynchronous server-side validation.  This particular item has not been resolved.  I posted a message with a list of options that I came up with to address this request.  If a secDNS:dsData or secDNS:keyData attribute needs to be added for the client to provide a hint to the server, than secDNS:chg is needed.        
   

I highly suggest that you have “the right people” take the time to look at the details of the changes as soon as possible to help drive 4310-bis along.  I’ve have many changes from the feedback and based on #1, #2, #3 above included in a 04 draft that has not been posted yet.  I really want to come to some sort of conclusion on #4 and I want to ensure that the list is fine with #3 prior to posting 04.  Any feedback you have on these items or any other elements of 4310-bis is greatly appreciated.

Thanks,


-- 


JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063

 
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, proprietary and/or Registry  Sensitive information intended solely for the recipient and, thus may not be  retransmitted, reproduced or disclosed without the prior written consent of  VeriSign Naming and Directory Services.  If you have received  this e-mail message in error, please notify the sender immediately by  telephone or reply e-mail and destroy the original message without making a  copy.  Thank you.

---

From: <Ray.Bellis@nominet.org.uk>
Date: Wed, 10 Feb 2010 06:19:47 -0500
To: EPP Provreg <ietf-provreg@cafax.se>
Subject: [ietf-provreg] 4310-bis progress

James,

What are the current plans for 4310-bis?  The IESG last call is due to expire next week, but there's been significant on-list debate around some aspects (e.g. schema versions for backwards compatibility, maxSigLife, etc).

I'm really just trying to get an idea of the potential future timeline for this document so that we can make sure the right people have time to look at the details of the changes.

Ray

--
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: ray@nominet.org.uk, t: +44 1865 332211