Re: 4310-bis progress

James Gould <[email protected]>
Newsgroups gmane.ietf.provreg
Message-ID <C7982F88.3750D%[email protected]>
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
[email protected]
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: <[email protected]>
Date: Wed, 10 Feb 2010 06:19:47 -0500
To: EPP Provreg <[email protected]>
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: [email protected], t: +44 1865 332211
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.