Re: [DNSOP] draft-yao-dnsop-idntld-implementation-01.txt

["YAO Jiankang" <[e-mail]>]

----- Original Message ----- 
From: "Andrew Sullivan" <[e-mail]>
To: <[e-mail]>
Sent: Friday, November 06, 2009 4:59 AM
Subject: [DNSOP] draft-yao-dnsop-idntld-implementation-01.txt


> Dear colleagues,
> 
> I have read the document
> draft-yao-dnsop-idntld-implementation-01.txt.  

thanks for your kind reading.

>I note that there is an
> agenda item on the DNSOP WG agenda to consider this draft.

it seems that you are not happy.  
:)
Fortunately, you are the chair of dnsext, not dnsop. otherwise, I may lose the opportunity 
:)

> 
> I am strongly opposed to the draft, and wish to express my opposition
> to it being adopted by the WG.  In my opinion, the draft places
> altogether too much confidence in the notion that data consistency can
> in any way be enforced across two completely different delegations.


if you read the draft carefully,  the draft does not enforce which method must be used. we provide many possible solutions.
since ICANN has approved the IDN ccTLD track, in a few months, there will have some IDN tld and its variant appearing in the root soon.

this draft submits a problem that should be solved and proposes a possible solution or suggestion. This draft is trying to be an informaitonal RFC, which may
help the TLD operators and internet community.

from your current wording, it seems that you oppose this draft because that the solution proposed is not your favor.
you does not oppose that the IDN TLD variants issue should be resolved.

if that is true, the reason that you oppose the draft is not reasonable.

whether the draft can be adopted as the working group document does not depend only on whether the solution is perfect.
sometimes, the problem submitted is more important. since you are the IETF WG co-chair, and I think that you know it better than me.

I hope that you as the DNSEXT co-chair has much knowlege about DNS protocols, could you provide more constructive suggestions to help this draft
instead of saying the words such as "I am strongly opposed to the draft" to kill this draft?


the first time you opposed this draft is that you said that this draft is not in the scope of the WG and you prefer the DNAME.
I cite the DNSOP charter sentences to prove that it is in the charter. 

now,  you just simply say that  "I am strongly opposed to the draft"  and have no contructive suggestions.

is there any other reasons you can not speak here in the list?

I have said many times that I submit a problem and propose a possible solution in the draft.
if the solution is not perfect, we can work togther to make it being perfect.

   
  
> 
> If we are to take at all the idea of variants seriously, then what we
> must suppose is that any name must be _functionally the same_ as all
> the other variants of that name.  The only mechanism we have in the
> DNS that approaches that functionality is DNAME. 

if we put DNAME into the root,  pls take a look at this presetation:
https://www.dns-oarc.net/files/workshop-200911/Ziqian_Liu.pdf,

in May 19, 2009, the China Telecom network collapsed due to the too much queries to DNS recursive servers .

if dname is put into the root , the accidents similar to May 19 affairs of China Telcecom network collapsing, and  the attacked recursive servers happen to be dname-unware, all the attacks to recursive servers will directly go to the root since dname-unware resolvers or recursive servers has the TTL zero.
some root servers may be down. Do you want to see this being happened?



> DNAME is far from
> ideal: it does not actually mirror the root of the tree, and there are
> other nasty issues (MX is an obvious one).  The authors are correct
> that a DNAME deployment could indeed lead DNS operators lower in the
> tree to do broken things.  But neither of those issues holds a candle
> to the mistaken notion that two actually different delegations may be
> relied upon to be the same.

I does not oppose the DNAME being used in the TLD level. I am not favor of putting the DNAME in the root.
I say that if DNAME is used, some issues should be considered.
if the solution is not perfect, we may try to make it better.

> 
> If we encourage NS delegation from the root into different zones that
> are supposed to be the same, then in the absence of complicated,
> as-yet-unwritten tools to enforce the lock step consistency of those
> different delegations (and to check them all the time), the chances of
> the different zones actually being the same all the time approaches
> zero.

the draft does not enforce that the NS should be used in the TLD level.
some TLD operators may prefer DNAME, some may prefer NS.
the draft gives some issues that should be considered when applying the DNAME or NS.

>  Since the principle of a variant is that it just be another
> spelling for the name (as though we granted colour.com automatically
> to the registrant color.com) any difference in the answer you get
> from the servers for one and the servers for another is by definition
> a problem.  
> 
> I appreciate the problems the authors are trying to solve, and I
> understand why they are taking this path; 

thanks for your kind understanding.

>but it is still the wrong
> path, and I believe it to be a greater threatl to the stability of the
> DNS than the introduction of DNAMEs near the top.

if you read the draft carefully, you will  find more than one path.
are all the paths wrong? If I understand it correctly, you may appreciate one of them. I know that you do not like the way of puting NS both in the root and in the TLD for IDN TLD variants.

I also introduced my draft at the dns-oarc meeting. if you have time, you can take a look at
https://www.dns-oarc.net/files/workshop-200911/Yao_Jiankang.ppt 

because I have only 5-10 minutes in the IETF DNSOP WG meeting, I hope we can discuss more in the list.
leave the meeting time to others who want to comment to this draft.

thans a lot for your kind comments and reading of the draft.

Yao Jiankang
CNNIC 





> 
> Best regards,
> 
> Andrew
> 
> -- 
> Andrew Sullivan
> [e-mail]
> Shinkuro, Inc.
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop