Re: [gnso-idn-wg] Unified rules within a DNS subtree

[subbiah <subbiah@xxxxxxxxx>]

Dear Sophia, Steve, Bruce

Just a slight correction. I note that Sophia suggested that I said ...

" And that it should just simply 
be made into a passive guidleines recommendation but a requirement to the
applicant in strong enforeacble contracts. (which Werner suggested)."

I think what I said and what I think she intended to say that I said (as 
the rest of her note makes clear later on) is onethat includea key "NOT"...

" And that it should NOT just simply 
be made into a passive guidleines recommendation but a requirement to the
applicant in strong enforeacble contracts. (which Werner suggested)."

Apart from that slip-up I think she summed up what I felt correctly - 
which Werner also I believe independently brought up. And I am also okay 
with Steve Croker's suggestion that even at the techncially 
unenforceable levels one can go further than my view (and what I think 
Bruce seperately said)  of  "best practice recomendation" in guidelines 
to one that contractually requires them to try their best to do so, even 
if there is no technical way of them enforcing it. Okay either way.

Cheers

Subbiah


Sophia B wrote:

>  
>
>             I was responding Cary's comment that they
>             only way to have a rule like "single script" work for an
>             entire
>             subtree is to have the entire subtree maintained within a
>             single
>             registry, and I was suggesting contractual enforcement,
>             culture, etc.
>             could also be used.
>
>  
> Yes, I am fully for this Steve,( as I suported it in the call by 
> saying it was a good
> compromise, when Subbiah made the original recommendation), ie. generally
> maybe necessary and that the applicant on a case-by-case will be 
> generously
> awarded what they need, without going to hunderds of scripts. (at the 
> enforceable
> levels - 1st, 2nd and in some cases the 3rd etc).  And that it should 
> just simply 
> be made into a passive guidleines recommendation but a requirement to the
> applicant in strong enforeacble contracts. (which Werner suggested). 
> At  the
> unenforceable levels, it should be a strong best practice recomendation
> mentioned in the contract. The genreal idea is to prevent in the future,
> hundreds of scripts and all manner of mixing them under single TLDs and
> limit it to only a small handful of mixing based on local community 
> needs as
> requested by applicant.
>
>  
> On 07/03/07, *Steve Crocker* <steve@xxxxxxxxxxxx 
> <mailto:steve@xxxxxxxxxxxx>> wrote:
>
>     Bruce,
>
>     I was also including in my thinking the possibility of having even
>     stronger contractual controls for all subordinate levels in newly
>     created TLDs if that turns out to be desirable.  I'm not necessarily
>     advocating this approach.  I was responding Cary's comment that they
>     only way to have a rule like "single script" work for an entire
>     subtree is to have the entire subtree maintained within a single
>     registry, and I was suggesting contractual enforcement, culture, etc.
>     could also be used.
>
>     Steve
>
>     Steve Crocker
>     steve@xxxxxxxxxxxx <mailto:steve@xxxxxxxxxxxx>
>
>     Try Shinkuro's collaboration technology.  Visit www.shinkuro.com
>     <http://www.shinkuro.com>.  I
>     am steve!shinkuro.com.
>
>
>     On Mar 7, 2007, at 1:26 AM, Bruce Tonkin wrote:
>
>     > Hello Steve,
>     >
>     >>
>     >> Responding to your point on the call, I think it's feasible
>     >> to have a
>     >> uniform set of rules, e.g. single script adherence, imposed on an
>     >> entire hierarchy even if the hierarchy is administered by multiple
>     >> zone administrators, but it means using contracts and strong
>     >> community enforcement instead of only mechanical checking.
>     >>
>     >
>     >
>     > It is really a balance between contractual enforcement and best
>     > practice.
>     >
>     > For gTLDs:
>     >
>     > - top level - ICANN contractual term with registry operator
>     >
>     > - second level  - ICANN contractual term with registry operator
>     >
>     > - third and lower level - best practice/education
>     >
>     > (note that some TLDs like .name do support third level directly
>     at the
>     > registry, and hence compliance could be managed at that level)
>     >
>     >
>     > For ccTLDs:
>     >
>     > - top level - ICANN contractual term with registry operator
>     >
>     > - second level - best practice/education
>     >
>     > - third and lower level -  - best practice/education
>     >
>     >
>     > To some degree application software can also highlight issues - e.g
>     > display a warning when mixed scripts are detected etc.
>     >
>     >
>     > Regards,
>     > Bruce Tonkin
>     >
>     >



--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.413 / Virus Database: 268.18.7/713 - Release Date: 3/7/2007