Provisioning Registry Protocol (provreg)

headers Wil Tan | 17 Oct 2011 16:36

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Dear Wil and Gavin,

great work!

I do have some "minor" comments:

1. After a claim has been invalidated an applicant may submit additional 
data offline or through an update and the claim goes from status invalid 
to valid or maybe even pending.

2. There is no possibility to update an application. There should be an 
lp:add lp:rem and lp:chg. Of course there could be restrictions based on 
the application status.

3. I would prefer more server considerations. "Server has to ensure that 
in the presence of an lp:xxx the command is processed as an launch phase 
application and not as ordinary domain:xxx command."

/Ulrich

> Dear colleagues,
>
> Gavin and I have published a new version of the draft:
> http://tools.ietf.org/html/draft-tan-epp-launchphase-01
>
> This is mostly Gavin's work, with the following changes:
>
> - element names are now in camelCase
> - renamed <trademark> to <claim>
> - a "preValidated" attribute of <claim> element
> - there can be one or more <claim> elements
>
> As usual, we'd love to hear any feedback that you may have.
>
> --
> .wil
> Cloud Registry <http://www.cloudregistry.net>
>
> ---------- Forwarded message ----------
> From: ** <internet-drafts <at> ietf.org <mailto:internet-drafts <at> ietf.org>>
> Date: Fri, Oct 14, 2011 at 3:16 AM
> Subject: New Version Notification for draft-tan-epp-launchphase-01.txt
> To: wil <at> cloudregistry.net <mailto:wil <at> cloudregistry.net>
> Cc: wil <at> cloudregistry.net <mailto:wil <at> cloudregistry.net>,
> gavin.brown <at> centralnic.com <mailto:gavin.brown <at> centralnic.com>
>
>
> A new version of I-D, draft-tan-epp-launchphase-01.txt has been
> successfully submitted by Wil Tan and posted to the IETF repository.
>
> Filename:        draft-tan-epp-launchphase
> Revision:        01
> Title:           Launch Phase Mapping for the Extensible Provisioning
> Protocol (EPP)
> Creation date:   2011-10-14
> WG ID:           Individual Submission
> Number of pages: 19
>
> Abstract:
>    This document describes an Extensible Provisioning Protocol (EPP)
>    extension mapping for the provisioning and management of domain names
>    during the launch phase of a domain name registry.
>
>
>
>
> The IETF Secretariat
>
>
> _______________________________________________
> provreg mailing list
> provreg <at> ietf.org
> https://www.ietf.org/mailman/listinfo/provreg
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Hi Ulrich,

> 1. After a claim has been invalidated an applicant may submit additional 
> data offline or through an update and the claim goes from status invalid 
> to valid or maybe even pending.

This is a good point. It may be that having a State Transition diagram
is impractical, as out-of-band processes could result in more
transitions than it's possible to represent.

> 2. There is no possibility to update an application. There should be an 
> lp:add lp:rem and lp:chg. Of course there could be restrictions based on 
> the application status.

I think this would be worth supporting.

> 3. I would prefer more server considerations. "Server has to ensure that 
> in the presence of an lp:xxx the command is processed as an launch phase 
> application and not as ordinary domain:xxx command."

Another good point.

Thanks,

--

-- 
Gavin Brown
Chief Technology Officer
CentralNic Ltd
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Ltd is a company registered in England and Wales with company
number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg

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
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg

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
jgould <at> Verisign.com

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

VerisignInc.com

On 10/25/11 12:27 AM, "Ning Kong" <nkong.cnnic <at> gmail.com> wrote:

>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
>_______________________________________________
>provreg mailing list
>provreg <at> ietf.org
>https://www.ietf.org/mailman/listinfo/provreg

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Hi Gould,

Thanks for reviewing this draft. Comments are inline below.

> Are you saying that the CDN's inherit all of the attributes of the OCDN
> 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
> 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?
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
> registry policy what other attributes (e.g. name servers, statuses) can be
> 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
> <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.
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
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg

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:
> Hi Gould,
>
> Thanks for reviewing this draft. Comments are inline below.
>
>> Are you saying that the CDN's inherit all of the attributes of the OCDN
>> 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
>> 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?
> 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
>> registry policy what other attributes (e.g. name servers, statuses) can be
>> 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
>> <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.
> 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
> _______________________________________________
> provreg mailing list
> provreg <at> ietf.org
> https://www.ietf.org/mailman/listinfo/provreg

-- 
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: jwagner <at> hexonet.net
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.

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg

On Wed, Oct 26, 2011 at 12:21:15PM +0200, Jens Wagner wrote:
> Furthermore, I'd prefer if there's no redundancy in responses, e.g.
> 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.

> <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.

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
ajs <at> anvilwalrusden.com

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Hi Andrew,

On 26.10.2011 12:42, Andrew Sullivan wrote:
> On Wed, Oct 26, 2011 at 12:21:15PM +0200, Jens Wagner wrote:
>> Furthermore, I'd prefer if there's no redundancy in responses, e.g.
>> 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.
>
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.

>> <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.
> 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.

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

-- 
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: jwagner <at> hexonet.net
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.

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg

9	June 2013
34	May 2013
61	April 2013
44	March 2013
27	February 2013
42	January 2013
72	December 2012
7	November 2012
16	October 2012
6	September 2012
73	August 2012
1	July 2012
2	May 2012
39	April 2012
82	March 2012
26	February 2012
161	January 2012
35	December 2011
8	November 2011
27	October 2011
17	July 2011
64	June 2011
20	May 2011
19	April 2011
3	March 2011
1	December 2010
9	September 2010
4	August 2010
3	July 2010
7	June 2010
2	May 2010
15	March 2010
48	February 2010
108	January 2010
16	December 2009
35	November 2009
34	October 2009
1	September 2009
11	August 2009
8	July 2009
33	April 2009
30	December 2008
5	October 2008
6	September 2008
4	April 2008
2	March 2008
5	January 2008
3	December 2007
13	October 2007
16	June 2007
1	May 2007
36	April 2007
7	March 2007
19	January 2007
9	December 2006
11	November 2006
4	October 2006
2	September 2006
15	August 2006
28	July 2006
32	June 2006
4	May 2006
5	April 2006
18	February 2006
5	November 2005
52	October 2005
30	September 2005
68	August 2005
27	July 2005
2	June 2005
1	April 2005
1	February 2005
7	November 2004
20	September 2004
2	August 2004
3	July 2004
1	June 2004
4	May 2004
24	April 2004
16	March 2004
10	January 2004
24	December 2003
7	November 2003
7	October 2003
4	September 2003
2	August 2003
15	July 2003
10	June 2003
28	May 2003
132	April 2003
135	March 2003
37	February 2003
87	January 2003
106	December 2002
95	November 2002
121	October 2002
68	September 2002
114	August 2002
87	July 2002
47	June 2002
21	May 2002
25	April 2002

Fwd: New Version Notification for draft-tan-epp-launchphase-01.txt

Re: Fwd: New Version Notification for draft-tan-epp-launchphase-01.txt

Re: Fwd: New Version Notification for draft-tan-epp-launchphase-01.txt

draft-kong-epp-cdn-dnssec-mapping-00 Submitted for Review

Re: draft-kong-epp-cdn-dnssec-mapping-00 Submitted for Review

Re: draft-kong-epp-cdn-dnssec-mapping-00 Submitted for Review

Re: draft-kong-epp-cdn-dnssec-mapping-00 Submitted for Review

Re: draft-kong-epp-cdn-dnssec-mapping-00 Submitted for Review

Re: draft-kong-epp-cdn-dnssec-mapping-00 Submitted for Review

Re: draft-kong-epp-cdn-dnssec-mapping-00 Submitted for Review

Mon	Tue	Wed	Thu	Fri	Sat	Sun

					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30
31