[DTD Authorization] Our Timetable

[David Conrad]

Maarten,

> Sounds good. I would though appreciate it if we could receive the formal
> existing procedures/process details with regard to the NTIA autorization
> function. 

While no harm comes from asking and I will do so informally (will look into
how a formal question can be raised with NTIA), I would be surprised if NTIA
provides anything more than a pointer to the presentation on their website
(already provided).  To be honest, I'm not sure there is much more than what
they describe there.

> From a ccTLD perspective two possibly conflicting arguments come to my mind:
> - the need for robust and secure procedures that should eliminate the risk of
> any mistakes as far as possible

Speaking personally, I don't believe the NTIA authorization step helps this
in any way (and arguments can be made that the introduction of the third
party makes securing the system harder).  Given the automated system and the
technical checks that system implements, mistakes are generally caught
either at the TLD Manager/IANA Function Manager point or (in very rare
cases) at the IANA Function Manager/Root Zone Maintainer point.  The only
mistakes the authorization step (as currently implemented) would catch would
be:
1. If the change request wasn't submitted securely
2. If the change request was malformed in some way
3. ICANN didn't say "yes, we followed our processes"
4. ICANN didn't ask "can this change request be processed"
Since 1 and 2 are generated by an automated system and the Root Zone
Maintainer side will only accept securely transmitted and properly formed
requests, the risk of mistakes here are minimal.  As for 3 and 4, I
personally question their value.

> - the need to have no other entity whatsoever to have any powers on IANA ccTLD
> matters and certainly not in delegation/redelegation matters.

I assume you mean no other entity than the TLD manager, the IANA Function
Manager, and the Root Zone Maintainer.   Obviously, explicit in the
authorization step is the ability of the authorizer (whoever it might be) to
refuse authorization.  If this constraint is a requirement, it would imply
the authorizer must be the TLD Manager, the IANA Function Manager, or the
Root Zone Maintainer and if so, the requirement could be met by removing the
authorization step (since it could be implemented by the TLD Manager not
submitting the change or the IANA Function Manager or Root Zone Maintainer
refusing the change).

Regards,
-drc



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/dt5/attachments/20150319/c32bea1d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4673 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/dt5/attachments/20150319/c32bea1d/smime.p7s>