I read your message line by line. thanks for your clarification. now your ideas, suggestions and concerns are more clear to me.
Yao Jiankang CNNIC ----- Original Message ----- From: "Andrew Sullivan" <[email protected]> To: <[email protected]> Sent: Saturday, November 07, 2009 2:03 AM Subject: Re: [DNSOP] draft-yao-dnsop-idntld-implementation-01.txt > On Fri, Nov 06, 2009 at 11:25:14PM +0800, YAO Jiankang wrote: > >> Fortunately, you are the chair of dnsext, not dnsop. otherwise, I >> may lose the opportunity :) > > Just for the record, in a case where I act as a chair, I try very hard > to reflect the will of the WG even if it is not my judgement that it > is a good idea. I should hope that participants hold me to such a > standard, and call me out in case they find I am not acting that way. > A recent example was the WG's decision to pull back the sha-2 draft > from the IESG because it did not like the aliasing mechanism in it. > > But you point out something important: I didn't note in my review that > I comment only as a participant of DNSOP and not in any other > capacity. > >> if you read the draft carefully, the draft does not enforce which >> method must be used. we provide many possible solutions. > > I believe I did read the draft carefully, and it seems to me that it > is written in such a way that it fails to address the basic issue > bothering me: different delegations are, by their very nature, > dangerous for this purpose and therefore should not be used. > >> 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. > > I am aware that ICANN has made that decision. It bothers me when > ICANN makes policy decisions with technical implications without, > apparently, having worked through all the technical implications. But > anyone who has been in any technical environment in all of history has > probably had that experience. Just because we have to do something > doesn't mean we have to do something wrong, and I am of the opinion > that using the NS strategy is wrong. The draft does not recommend > against it, so I oppose the draft as it stands. > >> 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 you want my real opinion, it is that the very idea of variants is > deeply mistaken, imports into the administration of the DNS a large > number of semantic issues that do not belong there, and involves a > number of naïve linguistic assumptions some of which were proven to be > false by (among others) Quine many years ago. But, since the crest of > the slippery slope is already behind us, we need to address the idea > of variants in its own terms. That means that the RNAMEs of a variant > must be precisely equivalent to all the other RNAMEs of which it is a > variant. If that is not what "variant" means, then a more rigorous > definition of "variant" is necessary. If it is what "variant" means, > however, then there is no way that separate delegations for the > different variants actually offers the precise equivalence needed. > DNAME does not, either, but it is much closer and therefore less > harmful to the idea that the two variants of one another are the same. > >> if that is true, the reason that you oppose the draft is not reasonable. > > I don't see how that follows. My reason is that the draft leaves open > a possibility that I consider fundamentally harmful to the operation > of the DNS. Why do you think that is an unreasonable position? > >> 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 > > I think my review offers a constructive suggestion: the draft should > actively suggest that using different NS records to delegate variants > is mistaken, because it does not guarantee the child sides of the > respective zone cuts are in fact the same. As an alternative, it > could recommend that tools be developed to ensure that the child side > of a variant RNAME is always only a DNAME to the "primary" name, and > that any delegation that fails to meet this requirement be immediately > removed from the parent zone. The fact is that this would still > potentially introduce more than 24 hours of potential confusion (since > the root zone is published twice a day and the TTL on NS records from > the root is longer than 24 hours). > >> 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. > > The message at > http://www.ietf.org/mail-archive/web/dnsop/current/msg07698.html does > not say that the draft is not in scope of the WG. I did argue that > there was a particular claim in the draft that didn't belong in output > of the WG; I'm delighted the subsequent update took that feedback into > consideration. Moreover, your characterization above appears to > ignore just about every substantive remark I made in the > aforementioned review. > >> now, you just simply say that "I am strongly opposed to the draft" >> and have no contructive suggestions. > > This is simply false. My suggestions remain the same as before: the > draft should recommend against using NS records to delegate two > different name spaces that are somehow supposed to be the same. > > I also suggest that the draft should make it quite plain to everyone > -- and particularly, to those who have to make policy about DNS > namespaces -- that there is as a matter of fact _no_ way to have two > namespaces be identical. DNAME comes closer than anything else, and > therefore it is the only reasonable choice for this purpose. > > That is the primary suggestion I made in response to the -00 draft, > and it remains my suggestion now. > >> 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? > > Your argument above is twofold. > > First, it depends on an analogy between the China Telecom network > failure and the root nameserver system. It is more or less impossible > for me, from my vantage point, to evaluate that analogy, because I > know almost nothing about the China Telecom deployment. Given that > the presentation seems to have a large number of recommendations on > how to avoid this, and given that some of those recommendations appear > to be technologies widely deployed in the root server operations, it > seems at least possible that the similarity is not enough to conclude > that what happened to the China Telecom systems could also happen to > the root nameservers. Any argument from analogy depends on the degree > of similarity of the two analogues, and so the more relevant > dissimilarities there are, the weaker the argument. As I argued > before, I think the DNS operators have to evaluate what the real risk > is here. > > Second, it implicitly relies on the premise, "Either DNAME or NS," > which is a conclusion that comes from the premise that we must have > variants. But I claim NS is not appropriate because it does not make > the two delegations equivalent. Therefore, we must use DNAME. If > DNAME does not work because it imposes too much load, then we simply > don't have the ability to support variants. > > I further argue that, if we suggest it possible to use NS records for > "variants", we're not actually adding variants at all. We're adding > new TLDs, and that's all there is to it. Some TLDs might have > contractual restrictions on what is allowed in them. So, just as > .aero is only allowed things that conform to the policies of SITA, one > might have a TLD that is required to contain all and only delegations > in some other zone. But that is entirely a contract matter, it is > firmly in the domain of ICANN and outside this WG's purview, and we > should not dress that contractual rule up as some sort of technique to > implement "variants". It isn't, because there's no technical > mechanism that ensures TLD1 and TLD2 contain the same data. I predict > -- indeed, I'd bet a pretty good meal on this -- that an NS-based > mechanism to implement the desired variant technology will result in a > new clasee of occasional inconsistencies that are sometimes > observable. > > I hope this makes clearer what I'm trying to say. > > Best regards, > > A > > -- > Andrew Sullivan > [email protected] > Shinkuro, Inc. > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
