Subject: [provreg] draft-kong-epp-cdn-dnssec-mapping-00 Submitted for Review

From: Ning Kong <[email-masked]>
Date: Tue, 25 Oct 2011 12:27:53 +0800

Hi folks,

I submitted http://www.ietf.org/id/draft-kong-epp-cdn-dnssec-mapping-00.txt
which proposes an extension of EPP DNSSEC mapping [RFC5910] especially
for variant Chinese Domain Names (CDNs). By this extension, a client
can create, add, and remove DS information or key data information for
more than one domain name in the same time through one EPP
transaction.

Any comments on this draft are welcomed.

Thanks,

Ning

---

From: "Gould, James" <[email-masked]>
Date: Tue, 25 Oct 2011 14:02:27 +0000

Ning,

Are you saying that the CDN's inherit all of the attributes of the OCDN
except for the DNSSEC attributes that can't?  Wouldn't it be easier and
more standard to treat the CDN's as separate domains related to the OCDN
that are automatically created when creating the OCDN, meaning that the
RFC 5910 could be used as is on a <domain:update> with the <domain:name>
element containing the CDN instead of the OCDN?  It would be up to
registry policy what other attributes (e.g. name servers, statuses) can be
set on a per CDN basis.  Since the CDN is linked to the OCDN the
<domain:create>, <domain:delete>, and <domain:transfer> wouldn't apply
directly the CDN's, but certainly <domain:check>, <domain:update>, and
<domain:info> could.  One extension that would be useful for CDN would be
to return the list of CDN's in a info response of the OCDN and to require
the CDN list on a transfer request of the OCDN to make it explicit from
the gaining Registrar that they're transferring the OCDN along with the
list of CDN's and that they support the management of CDN's.  Returning
the list of CDN's could be based on the inclusion of the CDN extension URI
in the login services.

A nit on the draft is to use camel case for the element names.

--

JG

James Gould
Principal Software Engineer
[email-masked]

703-948-3271
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

VerisignInc.com

On 10/25/11 12:27 AM, "Ning Kong" <[email-masked]> wrote:

>Hi folks,
>
>I submitted 
>http://www.ietf.org/id/draft-kong-epp-cdn-dnssec-mapping-00.txt
>_______________________________________________
>provreg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/provreg

---

From: Ning Kong <[email-masked]>
Date: Wed, 26 Oct 2011 17:03:54 +0800

Hi Gould,

Thanks for reviewing this draft. Comments are inline below.

> except for the DNSSEC attributes that can't?
Yes. Actually we hope all the CDNs could inherit all of the atrributes
of the OCDN. But because the DS must be bound with the name of CDN, so
the DNSSEC attributes of CDNs can't be same.

> Wouldn't it be easier and
> element containing the CDN instead of the OCDN?
We can do it as you suggest. But we don't think this method is easier.
Because a registrant who registers an OCDN will finally get several or
more CDNs. So if a registrant needs to update the DNSSEC attributes of
all the CDNs, he or she has to do this kind of operation one by one.
Moreover, any reserved variant CDN can be validated by the same
registrant later. If the quantity of CDNs is large, we think this
method is not convenient for registrants or registrars. So, we suppose
an extension of RFC 5910 to support bulk operations for CDNs.

> It would be up to
> set on a per CDN basis.
For Chinese users, the variants of a Chinese character in SC form, TC
form and other variant forms are regarded as the same. Most of Chinese
Domain Names (CDNs) have different variant forms (SC form, TC form,
and other variant forms) which are also regarded as the same by
Chinese users. So we think that all the CDN's should inherit all of
the attributes of the OCDN (except for the DNSSEC attributes) to avoid
the confusion of CDNs users.

>  Since the CDN is linked to the OCDN the
We have made such kind of extension in the draft
http://tools.ietf.org/html/draft-kong-epp-cdn-mapping-00. Any comments
on this draft are welcomed!

> A nit on the draft is to use camel case for the element names.
We think we use camel case for the element names. Could you please
tell us which elements names are wrong? Thanks!

Cheers,
Ning

---

From: Jens Wagner <[email-masked]>
Date: Wed, 26 Oct 2011 12:21:15 +0200

Hi Ning,

I agree with James. There should be an EPP extension to list domain 
variants via <info>, and maybe require them on transfer (server 
policy?), but it should cover more than chinese domain variants. As 
James pointed out, the variants could be managed using standard EPP, so 
there's no need to extend e.g. the <update> command. Imho that's 
convenient for registrars (being one myself), EPP doesn't support bulk 
updates/renews/transfers/deletes either.

Furthermore, I'd prefer if there's no redundancy in responses, e.g. 
variants should be returned in punycode only.

Something like

<var:infData>
<var:list>
<var:domain type='simplified-chinese'>xn--fiqu1az03c18t.cn</var:domain>
<var:domain type='traditional-chinese'>xn--fiq228c54pg81a.cn</var:domain>
<var:domain type='variant'>xn--fsq470a.xn--fiqz9s</var:domain>
</var:list>
</var:infData>

should do, where type is a text attribute, and could be e.g. 
'simple-chinese', 'traditional-chinese' and so on. For management 
purposes, the type doesn't really matter.

Such an extension could even make sense for domains with german umlauts; 
depending on how a registry handles IDNA2003 vs. IDNA2008, e.g. 
regarding fussball.com/fußball.com ;-)

Regarding the camel case, I think it should be e.g. scdn/scdnPunycode, 
instead of SCDN/SCDNPunycode.

Best,
-jens

On 26.10.2011 11:03, Ning Kong wrote:
>> RFC 5910 could be used as is on a<domain:update>  with the<domain:name>
>> <domain:create>,<domain:delete>, and<domain:transfer>  wouldn't apply
>> directly the CDN's, but certainly<domain:check>,<domain:update>, and

-- 
Jens Wagner
Chief Executive Officer
HEXONET GmbH
Be Your Own Internet Services Provider

T: +49 6841 69 84 0
F: +49 6841 69 84 199
E: [email-masked]
W: http://www.hexonet.net

HEXONET GmbH, Talstrasse 27, 66424 Homburg, Germany.  CEO&  General Manager: Jens Wagner, HRB 2839 (HOM), Amtsgericht Saarbrücken, VAT-ID: DE-138316882
HEXONET Services Inc., 1100 - 1200 West 73rd Avenue, Vancouver, B.C., V6P 6G5, Canada.  CSO&  General Manager: Robert Birkner

This email and any files transmitted are confidential and intended only or the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 26 Oct 2011 06:42:33 -0400

> variants should be returned in punycode only.

I don't think you can do that.  The Punycode form of IDNA2003 labels
is not lossless, so while you get what is in the DNS, you don't know
what the input string for the label was.

You could return only the A-label, of course, for IDNA2008, because
there's no ambiguity there (each A-label corresponds to exactly one
U-label).  But we're not in an IDNA2008-only world yet, and if you'd
meant to stick to IDNA2008, you'd have said "A-label" instead.

> purposes, the type doesn't really matter.

Where are these types going to come from?  The term "variant", I have
to say, has been so miserably overloaded that we have serious
problems with using it.

A
-- 
Andrew Sullivan
[email-masked]

---

From: Jens Wagner <[email-masked]>
Date: Wed, 26 Oct 2011 13:04:47 +0200

Hi Andrew,

> meant to stick to IDNA2008, you'd have said "A-label" instead.
for now, the extension needs to cover IDNA2003 too, imho we can't stick 
to IDNA2008 in the forseeable future.
But - do we need the unicode labels at all? The set of 'usable' domain 
names always matches the set of them encoded in punycode.

> to say, has been so miserably overloaded that we have serious

I've just made up some random types. For technical purposes, they don't 
matter, but as Ning's draft even defined different element names for 
them, I included them as an type. Instead of using some generic 
type='variant', it could be omitted, e.g.:

<var:domain>xn--fsq470a.xn--fiqz9s</var:domain>

The only purpose of the extension would be, that a registry can list all 
manageble domains derived from an original domain, right?

Best,
-jens

T: +49 6841 69 84 0
F: +49 6841 69 84 199
E: [email-masked]

HEXONET GmbH, Talstrasse 27, 66424 Homburg, Germany.  CEO&  General 
Manager: Jens Wagner, HRB 2839 (HOM), Amtsgericht Saarbrücken, VAT-ID: 
DE-138316882
HEXONET Services Inc., 1100 - 1200 West 73rd Avenue, Vancouver, B.C., 
V6P 6G5, Canada.  CSO&  General Manager: Robert Birkner

This email and any files transmitted are confidential and intended only 
or the person(s) directly addressed. If you are not the intended 
recipient, any use, copying, transmission, distribution, or other forms 
of dissemination is strictly prohibited. If you have received this email 
in error, please notify the sender immediately and permanently delete 
this email with any files that may be attached.

---

From: Wil Tan <[email-masked]>
Date: Thu, 27 Oct 2011 01:40:51 +1100

> names always matches the set of them encoded in punycode.
Whenever folks suggested that registries should collect the input string,
I've always wondered the practical utility of it other than as an FYI? I
think I've heard some arguments along the lines of "future-proofing".
Perhaps it could be useful in the transition to IDNA2008 (with the ß and
sigma, etc.) but still it can only be used as a partial aid. Moreover,
there's no guarantee that the registrar didn't submit the
ToUnicode(ToAscii(input)) version, in which case it's truly redundant as
Jens stated.

Andrew, could you share your reasoning?

.wil

---

From: "Gould, James" <[email-masked]>
Date: Wed, 26 Oct 2011 19:07:52 +0000

Ning,

> an extension of RFC 5910 to support bulk operations for CDNs.

I don't believe that I agree that doing the DNSSEC updates in bulk is
easier.  The same case could be made for making DNSSEC updates across an
unrelated set of domains in bulk since a registrant could have multiple
domains that they want to manage.  What if there is an error in adding or
removing DS in one or more of the CDN's in the bulk command?  Would you
then have to extend the response as well to indicate what the specific
errors are?  I believe that it's best to update the CDN's on a one-by-one
basis for DNSSEC instead of in bulk for simplicity, consistency, and
accuracy.  This way all of the existing interfaces can be used instead of
requiring the registrars to have to implement updates in bulk.  Providing
the CDN as the <domain:name> value in a standard <domain:update> with the
dnssec extension for managing the DS or keys with additional server-side
validation seems like the most straight forward approach to me.  I ask the
registrars what they think is the best?

> the confusion of CDNs users.

Your policy indirectly creates the variants when creating the OCDN while
our policy is to allow the creation of the OCDN and block the creates of
the variants.  A third model is to open up the registration of the
variants by the sponsoring registrar and registrant, where the OCDN and
CDN are related but are independently managed.  Building the inheritance
of all of the attributes into the interface makes it less flexible in
supporting different models and less flexible for the registrants.  What
if a registrant wanted to use a different set of name servers for a subset
of the CDN's and what if a registrant never intended to use one of more of
the CDN's at all.  I believe there can be related entities but that
requiring inheritance of all of the attributes is not flexible enough for
the different business models and for the registrars/registrants.

> on this draft are welcomed!

Thanks, I'll review it and provide my feedback.

> tell us which elements names are wrong? Thanks!

Examples include secCDNS:CDN, secCDNS:KEY, secCDNS:DS, where they should
be secCDNS:cdn, secCDNS:key, secCDNS:ds.

--

JG

James Gould

703-948-3271
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

VerisignInc.com

---

From: Peter Koch <[email-masked]>
Date: Thu, 27 Oct 2011 10:45:03 +0200

> the DNSSEC attributes of CDNs can't be same.

so, why not operate on DNSKEY only - instead of DS?

-Peter

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 27 Oct 2011 06:44:21 -0400

On Wed, Oct 26, 2011 at 01:04:47PM +0200, Jens Wagner wrote:

> for now, the extension needs to cover IDNA2003 too, imho we can't
> stick to IDNA2008 in the forseeable future.
> But - do we need the unicode labels at all? The set of 'usable'
> domain names always matches the set of them encoded in punycode.

It's of course true that the IDNA2003 Punycode-encoded label, or the
IDNA2008 A-label, is the only thing that actually gets looked up.  But
given that people seem to want variants, those variants are based on
the string requested by the originator of the registration request (we
usually call this the registrant).  But what qualifies as a variant is
at least partly determined by registry policy, the registry will need
to be able to evaluate the extent to which a UTF-8 label (in IDNA2003)
or U-label (in IDNA2008) has variants.

Moreover, IDNA2008 suggests that the repository evaluate the
U-label/A-label pair for conformance with one another, in order to
ensure that the A-label to be placed in the zone really corresponds to
the desired U-label (and that that U-label is a real U-label).  See
section 4.2.1 of RFC 5891.
 
> The only purpose of the extension would be, that a registry can list
> all manageble domains derived from an original domain, right?

Sure, but under IDNA2003, you can't be sure what that "original domain" is, because of the case folding and so on.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Thu, 27 Oct 2011 13:57:00 +0000

Peter,

Yes, you are correct that inheriting the DNSKEY of the OCDN across the
CDN's would work and the server would then generate the set of DS across
the OCDN and it's CDN's.  I guess the only question is whether you would
really want to share / inherit the key material, but that might make sense
for related domains like OCDN and CDN's.  I like the OCDN and CDN's to be
treated as separate entities, but if the CDN's are contained by the OCDN
and have to inherit the OCDN attributes, than use of the DNSKEY with the
Key Data Interface of RFC 5910 should meet the goal.

--

JG

James Gould

703-948-3271
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

VerisignInc.com

---

From: Wil Tan <[email-masked]>
Date: Sat, 29 Oct 2011 00:33:50 +1100

> or U-label (in IDNA2008) has variants.
I can't think of a case where the registry can't determine the variants
from the ToUnicode(ToAscii(input)) alone. The language/script variant
tables are constructed such that only the permitted codepoints after
mapping (IDNA2003), normalisation and case folding have been applied. I'd
expect that the internal data structures within registries' implementations
also similarly only operate on permitted code points.

So, if given the input UTF-8 label, the registry would only either store
and forget about it, or perform ToUnicode(ToAscii()) on it.

> section 4.2.1 of RFC 5891.
Practically, in an SRS environment, I'd expect this evaluation of
U-label/A-label pair to be done by the registrar, rather than the registry
(repository) because registrants should be educated about IDNA2008 rules at
the entry point, rather than being presented with a cryptic EPP error
message.

.wil

---

From: "Ning Kong" <[email-masked]>
Date: Sun, 30 Oct 2011 13:52:26 +0800

Hi James,

I think the essence of our debate is which model of CDN policy should be
accepted by CDN registries or registrars. If the third model you mentioned
is accepted, I agree with you that we don't need to extend RFC 5910.

IMHO, the flexibility of policy might cause the inconformity of the
attributes of CDNs, and then maybe cause the confusion to CDN users. So we
prefer to choose the "inflexibility" of policy in order to reduce the risk
of confusion. Then we are trying to extend RFC 5731 and RFC 5910 to provide
some ways to simplify the heritance of all of the attributes among CDNs. By
these extensions, CDN registries or registrars can operate CDNs as a group,
and they can easily create or modify the attributes among CDNs even if the
quantity of CDNs is large. You know, our policy creates the SCDN and TCDN
when creating the OCDN and blocks the VCDNs in the same time. In the future,
our policy will allow the creation of the VCDNs by the same registrant. So
in theory, all the CDNs of an OCDN can be validated by a registrant, so the
quantity of CDNs could be huge.

In short, IMO if the flexibility of CDN policy is accepted, it's not
necessary to extend RFC 5910 or RFC 5731. If the "inflexibility" of CDN
policy is accepted, the extensions of RFC 5731 and RFC 5910 supposed by us
might be useful to CDN registries (e.g. CNNIC) or registrars.

> Examples include secCDNS:CDN, secCDNS:KEY, secCDNS:DS, where they
> should be secCDNS:cdn, secCDNS:key, secCDNS:ds.
Thank you. I'll modify them in the next version.

Ning

> -----Original Message-----
> From: Gould, James [mailto:[email-masked]]
> Sent: Thursday, October 27, 2011 3:08 AM
> To: Ning Kong
> Cc: [email-masked]
> Subject: Re: [provreg] draft-kong-epp-cdn-dnssec-mapping-00 Submitted for
> Review
> 
> Ning,
> 
easier.
> The same case could be made for making DNSSEC updates across an unrelated
> set of domains in bulk since a registrant could have multiple domains that
> they want to manage.  What if there is an error in adding or removing DS
in
> one or more of the CDN's in the bulk command?  Would you then have to
> extend the response as well to indicate what the specific errors are?  I
> believe that it's best to update the CDN's on a one-by-one basis for
DNSSEC
> instead of in bulk for simplicity, consistency, and accuracy.  This way
all of
> the existing interfaces can be used instead of requiring the registrars to
have
> to implement updates in bulk.  Providing the CDN as the <domain:name>
> value in a standard <domain:update> with the dnssec extension for managing
> the DS or keys with additional server-side validation seems like the most
> straight forward approach to me.  I ask the registrars what they think is
the
> best?
our
> policy is to allow the creation of the OCDN and block the creates of the
> variants.  A third model is to open up the registration of the variants by
the
> sponsoring registrar and registrant, where the OCDN and CDN are related
but
> are independently managed.  Building the inheritance of all of the
attributes
> into the interface makes it less flexible in supporting different models
and less
> flexible for the registrants.  What if a registrant wanted to use a
different set
> of name servers for a subset of the CDN's and what if a registrant never
> intended to use one of more of the CDN's at all.  I believe there can be
> related entities but that requiring inheritance of all of the attributes
is not
> flexible enough for the different business models and for the
> registrars/registrants.
> 
> Examples include secCDNS:CDN, secCDNS:KEY, secCDNS:DS, where they
> should be secCDNS:cdn, secCDNS:key, secCDNS:ds.
> 
> --
> 
> 
> JG

---

From: "Ning Kong" <[email-masked]>
Date: Sun, 30 Oct 2011 14:05:52 +0800

Hi Peter,

> so, why not operate on DNSKEY only - instead of DS?

I also think the use of the DNSKEY with the Key Data Interface is more
convenient. Because the DS Data Interface is defined by RFC 5910, I think
it's difficult to forbid CDN registrars to use the DS Data Interface. So we
extended both interfaces in our draft.

Ning

---

From: "Gould, James" <[email-masked]>
Date: Mon, 31 Oct 2011 13:16:45 +0000

Ning,

RFC 5910 defines both the DS Data Interface and the Key Data Interface,
where the Registry must support one or the other except during a
transition period.  If the Registry supported the Key Data Interface
instead of the DS Data Interface the inheritance model that you're looking
for would be met with a greatly simplified interface for the registrars.

--

JG

James Gould

703-948-3271
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

VerisignInc.com

---

From: "Gould, James" <[email-masked]>
Date: Mon, 31 Oct 2011 13:39:24 +0000

Ning,

To meet your requirement of having a domain and it's variants inherit the
same attributes the Key Data Interface of RFC 5910 could be used.  If the
clients need to be able to explicitly set DS instead of keys (DS Data
Interface), then RFC 5731 along with RFC 5910 can be used by setting the
<domain:name> element of RFC 5731 to the variant domain name.  This does
mean that the DS for the domain and the variants are managed in separate
commands.  The key value of the extension that you drafted is managing the
DS in bulk.  My suggestion is to support managing the DS individually with
RFC 5731 and RFC 5910 and to make your extension as an option for
registrars that have the need to manage them in bulk.  It would be good to
hear from the registrars if managing DS in bulk is needed.

--

JG

James Gould

703-948-3271
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

VerisignInc.com

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 31 Oct 2011 10:33:19 -0400

> hear from the registrars if managing DS in bulk is needed.

It would be good to have a definition of "variant" that allows us to
know the answer.  Half the problem with these discussions is that the
meaning of variant is so fluid.

There are currently two competing definition of Chinese Domain Name,
one of which requires them all to have effectively the same DNS data
and another of which explicitly intends to use the DNS for application
support, with different RDATA for different A-label names (even though
the different A-labels are conceptually "the same name").  This basic
confusion in terms makes generalizing and standardizing the behaviour
of such things rather tricky.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Kevin Tes <[email-masked]>
Date: Tue, 01 Nov 2011 10:26:29 +0800

James,

Firstly,in this draft
http://tools.ietf.org/html/draft-kong-epp-cdn-mapping-00,
it allows the registrant to create domain and its related variant
domains by <domain:create>,if the registrant want to and new variant
domain or delete the exit variant domain, he/she can do it by
<domain:update>.
The registrant can do this operation by using any type of the domain,not
just the OCDN, that is to say, the registrant can use any type of the
domain(may be ocdn,tcdn,scdn,or vcdn)in the <domain:name>element to do
this operation,but the operation is for all of these domains(for they
shared the same elements).The registries (registrars)do not care which
type of the domain the registrant used, they just maintain the bulk
relationship of it. So it is was easy for registry and registrar to
operate IDN which may have many variants.

The registrant can use <domain:info>to get the domains(ocdn,scdn and so
on).

In this case,it is useful to extend the 5910 to meet this feature.
The registrant can use any type of the domain to do operation such as
update、create、info、delete and so on.

This extension allows the registrant add ds by specifying the domain
name,or add key data by specifying the "type = all, or type = sc".
I think this way is convenient not only for the registrant but also for
the registry and registrar.

xiejiagui

---

From: "Ning Kong" <[email-masked]>
Date: Tue, 1 Nov 2011 14:48:01 +0800

Hi James,

> same attributes the Key Data Interface of RFC 5910 could be used.
IMO, the Key Data Interface of RFC 5910 is only designed for single domain
name. So I think it's necessary to extend the <secDNS:keyData> element (for
example < secDNS:keyData type="single/bulk">) in order to let the users
(registrars/registries) know whether the key is for single domain name or
bulk.

> The key value of the extension that you drafted is managing the DS in
bulk.
> My suggestion is to support managing the DS individually with RFC 5731 and
> RFC 5910 and to make your extension as an option for registrars that have
the
> need to manage them in bulk. It would be good to hear from the registrars
> if managing DS in bulk is needed.
Thanks for your partly positive comments. I do hope to get more comments
from the registrars. That's why I sent email on this mailing list ;-)  IMHO,
I think our extension might be useful to not only registrars but also
registries. So I do hope we can hear from more registries related on CDN
registration.

Ning