[DT-F] REVISED: Design Team F kickoff

[David Conrad]

Chuck,

>>As mentioned in a previous note, I believe an appeals panel is probably
>>a reasonable requirement to recommend, however it obviously would only
>>have impact after the fact.
>[Chuck Gomes] It seems to me that one relatively simple way to deal with
>this 

There are a number of potential solutions (I have my favorites and the one
you suggest has merit), but I don't think this is the right place/time to
explore these. I think coming up with requirements as opposed to
implementation is a more productive route given the time and other
constraints we're under.

>[Chuck Gomes] I think it is important that everyone understand what is
>meant that " the Root Zone Maintainer is positioned to provide
>independent third-party intervention to operationally prevent a limited
>set of "out of policy" changes (specifically, requests that don't meet
>the policy relating to certain technical requirements)."  I would
>probably not use the word 'policy' hear but rather just say 'technical
>requirements'.  Hopefully everyone understands that the Root Zone
>Maintainer would not be able to identify compliance with non-technical
>policies coming from the policy development side of ICANN in the GNSO and
>ccNSO.

Right, apologies if there was any confusion relating to my terminology.
>From an operational perspective, I view the community-specified technical
criteria as simply additional policy constraints that must be met prior to
moving forward with a change request.

Regards,
-drc
-------------- 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/cwg-dtf/attachments/20150409/19b3fdef/smime.p7s>