[gtld-tech] "zfa-passwords" vs CZDS

[Kal Feher]

I support removing the field or allowing it to be perpetually 0 (which is probably the least disruptive to all parties for now). As it stands, the data supplied across all TLDs as part of this report is now of unreliable veracity, <- which is the opposite of data ICANN could retrieve from the CZDS. 

As a general principle, reports such as these which are released to the public,  should seek to have as accurate and verifiable data as possible. A necessarily manual process will undermine this principle.

Separately, I'd be interested to hear from ICANN whether the CZDS will ever provide an API to TLD operators allowing them to retrieve information and possibly update it as well. Is there a CZDS feature roadmap I've missed?

--
Kal Feher

-----Original Message-----
From: gtld-tech-bounces at icann.org [mailto:gtld-tech-bounces at icann.org] On Behalf Of Gould, James
Sent: Thursday, 27 March 2014 6:43 AM
To: Luis Muñoz; John R Levine
Cc: gtld-tech at icann.org
Subject: Re: [gtld-tech] "zfa-passwords" vs CZDS

I believe the zfa-password report field is a legacy field prior to the definition of the CZDS.  Prior to the CZDS, the registry systems were authoritative for the zone file applicants, since they directly made the zone files available to the applicants.  With the CZDS, the zone files are provided to the CZDS for distribution to the zone file applicants with no additional system-to-system integration.  The CZDS has the registry operator as an actor in the CZDS workflow for additions, but the registry systems are not involved at all.  Is the registry operator also in the flow for removals?  If not, there is no way that the count will be accurate using the ³little black notebook² approach.  It is the registry systems that generate the report, so the question is whether it¹s worth attempting to propagate the zfa-password counter manually from the CZDS to the registry systems for inclusion in the report to ICANN?  I don¹t believe it makes much sense to add this complexity for a field that ICANN can get an authoritative answer for using CZDS.  My recommendation is to remove this field altogether or populate the value with a place holder value (e.g. empty, ³0", "N/A², ³CZDS") in light of the CZDS.

Can ICANN respond to this so that we can come to an agreement on the best approach? 

Thanks,

-- 
 
JG
 

 
James Gould
Principal Software Engineer
jgould at verisign.com
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com




On 3/26/14, 2:54 PM, "Luis Muñoz" <lem at isc.org> wrote:

>
>On Mar 26, 2014, at 7:31 AM, John R Levine <johnl at taugh.com> wrote:
>
>> Yes, I realize that, but if a registry's processes are so sloppy that 
>>it doesn't remember whose CZDS access applications it's approved, it's 
>>hard to have a lot of sympathy.
>
>Why would your "un-sloppy" process need to "remember" something that is 
>being kept track of in a database, with an actionable audit trail? You 
>can have a perfect process that does depend on the existence of a 
>database.
>
>What happens when you lose the little black notebook where you kept 
>track of who you authorized access to what? Or do you build yet another 
>system to keep a redundant counter around?
>
>Best regards
>
>-lem
>