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

From: "YAO Jiankang" <[email-masked]>
Date: Fri, 6 Nov 2009 23:25:14 +0800

----- Original Message ----- 
From: "Andrew Sullivan" <[email-masked]>
To: <[email-masked]>
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
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 6 Nov 2009 13:03:40 -0500

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.

> 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 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-masked]
Shinkuro, Inc.

---

From: Kim Davies <[email-masked]>
Date: Fri, 6 Nov 2009 10:19:43 -0800

On 6/11/09 10:03 AM, "Andrew Sullivan" <[email-masked]> wrote:
> apparently, having worked through all the technical implications.

To be clear, ICANN has not made a decision to insert variants in the root,
precisely because there are implications that haven't yet been resolved. The
language of the implementation that was approved at ICANN's meeting last
week reads:

"The topic of delegation of variant TLDs and management of variant TLDs has
been discussed broadly in the community. ICANN staff has proposed a few
models, none of which were agreeable across the policy and technical
community reviewing the topic.

In order to stay within ICANN's mandate for ensuring a stable and secure
operation of the Internet, the following will be the case for the Fast Track
Process launch: 

1. Variant TLDs desired by the requester for delegation must be indicated by
the requester 

2. Desired variant TLDs will be allocated to the requester (if successfully
evaluated). This does not mean that the variant TLD will be delegated in the
DNS root zone. It will be allocated to the requester in order to be reserved
to the entitled manager for potential future delegation in the DNS root
zone.  

3. A list of non-desired variants will be generated based on the received
IDN Tables.  Non-desired variants will be placed on a blocked list by ICANN.
Subsequent application or request for non-desired variants will be denied."

kim

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 6 Nov 2009 13:24:34 -0500

On Fri, Nov 06, 2009 at 10:19:43AM -0800, Kim Davies wrote:

> precisely because there are implications that haven't yet been resolved.

Oh, that's good news.  Thanks for correcting my mistake.  The policy
that's actually been adopted seems to me to be an excellent one, and
I'm delighted to be set right.  My apologies for maligning the
decision incorrectly.

Best,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Alireza Saleh <[email-masked]>
Date: Fri, 06 Nov 2009 22:57:33 +0330

Variants can exist in registered IDN label no matter of where this label 
going to be used, TLD, SLD or other levels. I'm not trying to push 
having or not having variants in the root , I  would like to say that  
registries thinking about supporting variants and some currently do 
variant registration. what happen if their variant policy contains their 
proposed TLD label. " Think that in some cases there is no visual way to 
tell to variant labels apart".
So in that situation,  the variant issue  needs to be addressed 
somewhere else or should be completely forgotten.  If it is going to be 
supported, then this may happen at application level to override the 
decision which currently being made by DNS with replacing the variant 
TLD with the resolvable one.

I think that  ICANN may insert variants in the root if they do that 
according to a clear contract with the registry.

- Alireza

---

From: "YAO Jiankang" <[email-masked]>
Date: Mon, 9 Nov 2009 08:15:03 +0800

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