Subject: [provreg] IDN administrative bundling

From: Benoit Levac <[email-masked]>
Date: Thu, 29 Mar 2012 21:46:41 -0400

CIRA is considering the implementation of administrative bundling for the release of French character IDNs in the registry.  Under the proposed policy, each IDN domain would be independent from a registration and DNS management perspective.  However, all domains that share the same canonical form as defined by our policy (café.ca, cafe.ca, çafe.ca ...) would have to be registered by the same registrar and to the same registrant contact id.

We have started discussing the registry implementation, and one of the biggest challenges comes with registrar transfers or the updating a domain's registrant contact id.  Under our proposed policy we have to find a way to ensure that all registered variants maintain the same registrar and registrant contact.

The most promising implementation proposal is to queue the update and transfer requests until a request has been submitted for all variants in a bundle.  While we wait for all actions, would apply "pendingTransfer" and "pendingUpdate" statuses as described in sections 2.3 and 3.3 of RFC 5731.

1 - Does anyone know of a similar domain bundling policy so that we could look at its implementation?  Or might there be an RFC that would define something similar?

2 - Does anyone on this list have experience for using offline review of requested actions other than transfer?  Is there anything we should be careful about in picking this implementation?

3 - With domain transfer, there is a defined way of cancelling a pending transfer (as per section 2.9.3.4 of RFC 5730), but for a pending domain update, there is no defined way to cancel a pending operation.  Any suggestions out there.

Ben

---

From: Francisco Obispo <[email-masked]>
Date: Thu, 29 Mar 2012 19:05:57 -0700

On Mar 29, 2012, at 6:46 PM, Benoit Levac wrote:

> 1 – Does anyone know of a similar domain bundling policy so that we could look at its implementation?  Or might there be an RFC that would define something similar?
>  
> 2 – Does anyone on this list have experience for using offline review of requested actions other than transfer?  Is there anything we should be careful about in picking this implementation?
> 
>  
you could treat them as a bundle, so if you get a transfer or registrant update request, you will always apply the change to the whole set… It would be useful for you to have some sort of messaging mechanism to let the registrar know that the change/action has been applied to all, this could be done via an EPP message, or via some custom extension.

I think the most difficult part of this implementation, is to define upfront how to do the bundling… that is, how do you know that those names (café.ca, cafe.ca, çafe.ca …) are to be treated as a bundle?

>  
> 3 – With domain transfer, there is a defined way of cancelling a pending transfer (as per section 2.9.3.4 of RFC 5730), but for a pending domain update, there is no defined way to cancel a pending operation.  Any suggestions out there.

If you are just waiting for the registrar to send the same command over and over again until it completes the names in the bundle, why don't you process it upfront with the first one?

In any case, it seems like if you don't do the bundle treatment, you will have to code your own extension to manage it.

Francisco Obispo 
email: [email-masked]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 30 Mar 2012 04:12:28 +0200

> If you are just waiting for the registrar to send the same command over and over again until it completes the names in the bundle, why don't you process it upfront with the first one?

The main difference between the two models is whether the registry should do changes that are to be reflected in the registrar database, or whether the registrar should do all commands.

I am personally as a registrar in favor of the latter. That the registry should really minimize the number of changes made that have to be reflected in the registrar database. And because of that it is better if the status is "pending" until the registrar have made changes to all objects involved.

Is there an alternative when some domain names in the bundle is not registered? Not delegated? Requirements on same delegation of all of them? I.e. I think we have a generic issue related to bundles to discuss.

Similar problems happens when both the holder and the registrar changes for a domain name in the bundle btw. How do you handle the contact object when changes happens to the domain object?

But, just like Francisco I also ask what mechanism is to be used to ensure the registrant and registrar (and everyone else) know what domain names are in the bundle? Orthogonal question, but also important.

   Patrik

---

From: Kevin Tes <[email-masked]>
Date: Fri, 30 Mar 2012 10:17:11 +0800

Hi, I do think this draft
"http://tools.ietf.org/html/draft-kong-epp-idn-variants-mapping-00" may
help you a lot.

In this draft,it let the registrant to create 'bundle' members in epp
<domain:create> command and let the registrant 'add' or 'rem' bundle
members in <domain:update> command.All the members in this bundle share
the same informations.

Renew and Transfer ,Delete command are all to this bundle.

On Thu, 2012-03-29 at 21:46 -0400, Benoit Levac wrote:
> CIRA is considering the implementation of administrative bundling for
> the release of French character IDNs in the registry.  Under the
> proposed policy, each IDN domain would be independent from a
> registration and DNS management perspective.  However, all domains
> that share the same canonical form as defined by our policy (café.ca,
> cafe.ca, çafe.ca …) would have to be registered by the same registrar
> and to the same registrant contact id.
> 
>  
> 
> We have started discussing the registry implementation, and one of the
> biggest challenges comes with registrar transfers or the updating a
> domain’s registrant contact id.  Under our proposed policy we have to
> find a way to ensure that all registered variants maintain the same
> registrar and registrant contact.
> 
>  
> 
> The most promising implementation proposal is to queue the update and
> transfer requests until a request has been submitted for all variants
> in a bundle.  While we wait for all actions, would apply
> “pendingTransfer” and “pendingUpdate” statuses as described in
> sections 2.3 and 3.3 of RFC 5731.
> 
>  
> 
> 1 – Does anyone know of a similar domain bundling policy so that we
> could look at its implementation?  Or might there be an RFC that would
> define something similar?
> 
>  
> 
> 2 – Does anyone on this list have experience for using offline review
> of requested actions other than transfer?  Is there anything we should
> be careful about in picking this implementation?
> 
>  
> 
> 3 – With domain transfer, there is a defined way of cancelling a
> pending transfer (as per section 2.9.3.4 of RFC 5730), but for a
> pending domain update, there is no defined way to cancel a pending
> operation.  Any suggestions out there.
> 
>  
> 
> Ben
> 
> 
> _______________________________________________
> provreg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/provreg

---

From: Benoit Levac <[email-masked]>
Date: Thu, 29 Mar 2012 22:42:35 -0400

Patrik, Francisco,

Thank you for your comments.  I've added comments inline below.

Ben

-----Original Message-----
From: Patrik Fältström [mailto:[email-masked]] 
Sent: March-29-12 10:12 PM
To: Francisco Obispo
Cc: Benoit Levac; [email-masked]
Subject: Re: [provreg] IDN administrative bundling

> I am personally as a registrar in favor of the latter. That the registry should really minimize the number of changes made that have to be reflected in the registrar database. And because of that i…

Actually that is exactly the reason why we are leaning towards using "pending" statuses as opposed to automatically applying the actions to all variants.  For example, a registrar which has not prepared their systems for these changes could end up transferring multiple domains after submitting a single transfer for a single domain.  It also means that they would be charged for all of these domains (one request could cause a charge for multiple transfers).

> Is there an alternative when some domain names in the bundle is not registered? Not delegated? Requirements on same delegation of all of them? I.e. I think we have a generic issue related to bundle…

Under our currently proposed administrative bundling, each domain object is managed independently.  So there is no requirement on delegation.

> Similar problems happens when both the holder and the registrar changes for a domain name in the bundle btw. How do you handle the contact object when changes happens to the domain object?

In our current system, when domains are transferred, we create a clone of the contact objects sponsored by the gaining registrar and assign them to the domain.  Because all of the variants would have the same contact at the loosing registrar, we would assign a clone of that contact to all the variants when the transfer takes place (which would happen to all the variants at the same time).

> But, just like Francisco I also ask what mechanism is to be used to ensure the registrant and registrar (and everyone else) know what domain names are in the bundle? Orthogonal question, but also i…

We are just starting to define our implementation, but the current proposal is that the info command could return a list of allocated variants as part of an extension.  This would only be returned to the sponsoring registrar, or a non-sponsoring registrar with the auth-code.

---

From: Wil Tan <[email-masked]>
Date: Fri, 30 Mar 2012 13:45:53 +1100

> In this draft,it let the registrant to create 'bundle' members in epp

and

On Fri, Mar 30, 2012 at 1:05 PM, Francisco Obispo <[email-masked]> wrote:

> you could treat them as a bundle, so if you get a transfer or registrant
> update request, you will always apply the change to the whole set…
>

According to Ben, keeping the domains "independent from a registration and
DNS management perspective" is an explicit requirement. In that case,
bundling (in the RFC4290 / RFC3743 sense) wouldn't help. If it was just a
sunrise/grandfathering process as with AFNIC's upcoming launch of French
IDNs, you could accept domain creation requests during the process window
and handle it in batch mode. Then again, AFNIC's implementation does not
seem to require the same registrant or registrar of record once the domains
are created.

In any case, it seems like if you don't do the bundle treatment, you will
> have to code your own extension to manage it.

Yes, an extension to force the registrar to realise that there are other
domains in the administrative bundle, and send those along in create,
update and transfer requests. Once the registry verifies that the bundle
members are correct, it can effect the change on all of them.

.wil

---

From: James Mitchell <[email-masked]>
Date: Fri, 30 Mar 2012 16:37:31 +1100

Why treat each variant as a separate domain object that "can" be managed independently when they actually can't?

What if you promote the bundle to be a first class object having a canonical form, registrant contact, sponsoring registrar etc and have the domain names as attributes of that object. The domain names can be used as keys into the bundle when mapped onto interfaces such as EPP and WHOIS. You do get into a bit of an ugly however as update domain1 change registrant also changes domain2..n, however you could restrict updates to only the primary registered domain name pushing variant names into the background.

On the other hand you have to deal with pendingUpdate, registrars failing to submit updates for all domains, registrars sending incompatible updates etc.

James

From: Benoit Levac <[email-masked]<mailto:[email-masked]>>
Date: Fri, 30 Mar 2012 12:46:41 +1100
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [provreg] IDN administrative bundling

CIRA is considering the implementation of administrative bundling for the release of French character IDNs in the registry.  Under the proposed policy, each IDN domain would be independent from a registration and DNS management perspective.  However, all domains that share the same canonical form as defined by our policy (café.ca, cafe.ca, çafe.ca …) would have to be registered by the same registrar and to the same registrant contact id.

We have started discussing the registry implementation, and one of the biggest challenges comes with registrar transfers or the updating a domain’s registrant contact id.  Under our proposed policy we have to find a way to ensure that all registered variants maintain the same registrar and registrant contact.

The most promising implementation proposal is to queue the update and transfer requests until a request has been submitted for all variants in a bundle.  While we wait for all actions, would apply “pendingTransfer” and “pendingUpdate” statuses as described in sections 2.3 and 3.3 of RFC 5731.

Ben

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 30 Mar 2012 01:49:11 -0400

> Why treat each variant as a separate domain object that "can" be managed independently when they actually can't?

I can see one reason: no requirement of a completely new EPP object
type.  This isn't nothing.

Also, EPP already has to support registry policies that place
restrictions on what you can do to a name even though the restriction
isn't reflected anywhere in the registry; we call this "registry
policy" usually.  For instance, some names require a "presence"
requirement be fulfilled.  The presence precondition is satisfied by
the address value in the primary contact associated with the domain.
You can tell, if you look, whether a given contact object will satisfy
a given presence precondition, but there's no way to tell just by
looking at a name whether some contact or other will fulfill its
presence preconditions.  

(Nevertheless, there is something that feels unnatural under EPP about
linking different objects together this way, however loosely.)

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: mike <[email-masked]>
Date: Fri, 30 Mar 2012 09:11:52 +0200

Hi Ben,
> 3 – With domain transfer, there is a defined way of cancelling a pending transfer (as per section 2.9.3.4 of RFC 5730), but for a pending domain update, there is no defined way to cancel a pending…
We have a draft extension for cancelling pending actions on the registry, this allows the registrar to cancel a suspension, deletion, update, or deletion due to expiry by the action name. This creates some pretty complex policy handling esp. when expiry was due to non payment and cancelling that action results in billing. If you want a copy we can submit it for draft review.

Kind Regards,

Mike

co.za

---

From: James Mitchell <[email-masked]>
Date: Fri, 30 Mar 2012 18:45:54 +1100

One could implement variant domain names as attributes of the primary
domain name achieved through the use of object extensions preserving the
domain object mapping. Underneath the registry object can still be a
bundle having a canonical form, primary domain name, registrant contact
etc and a list of (activated) variant domain names.

Treating all names as individual yet linked domain names does not make
much sense for both registry and registrar if the variant model is "you
can have this variant on the condition that it is identical to the primary
name".

James

On 30/03/12 4:49 PM, "Andrew Sullivan" <[email-masked]> wrote:

>> Why treat each variant as a separate domain object that "can" be
>>managed independently when they actually can't?
>> 
>

---

From: Frederico A C Neves <[email-masked]>
Date: Fri, 30 Mar 2012 05:14:11 -0300

Benoit,

> 1 - Does anyone know of a similar domain bundling policy so that we could look at its implementation?  Or might there be an RFC that would define something similar?

This is almost exactly what we do for IDN registrations in .br since
2005 [1], but we do the "equivalence check" only at registration time
leveraging the fact that .br require a unique public organization
identifier. After initial registration the maintenance of the
"holdership" of the domain is up to the registrant as long as the
domain name is not canceled.

...
> Ben

Fred

[1] http://registro.br/anuncios/20050504.html (3rd paragraph
portuguese only)

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 30 Mar 2012 05:24:57 -0400

> can have this variant on the condition that it is identical to the primary

But of course, they're _not_ identical.  They're different names, and
in Latin they might not even be labels that anyone would ever actually
use (at least on purpose without fraudulent intent).

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Benoit Levac <[email-masked]>
Date: Fri, 30 Mar 2012 08:29:16 -0400

> One could implement variant domain names as attributes of the primary domain name achieved through the use of object extensions preserving the domain object mapping. Underneath the registry object can still be a bundle having a canonical form, primary domain name, registrant contact etc and a list of (activated) variant domain names.

We did consider the notion of adding an EPP bundle mapping object, but as mentioned by Andrew, the complexity and effort required for that option was not negligible.  

As for variants being attributes of domain object, that would cause an issue if we wish to allow registrars to manage DNS on each variant independently.

> Treating all names as individual yet linked domain names does not make much sense for both registry and registrar if the variant model is "you can have this variant on the condition that it is identical to the primary name".

While I agree conceptually that there is something unnatural about the administrative link, I do second Andrew's point that this could be viewed as registry policy.  I think the important part here is to make sure that registrars can get information regarding availability of a variant as well as the other variants of particular domain in a bundle.

Cheers,

Ben

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Sullivan
Sent: March-30-12 5:25 AM
To: [email-masked]
Subject: Re: [provreg] IDN administrative bundling

On Fri, Mar 30, 2012 at 06:45:54PM +1100, James Mitchell wrote:
> much sense for both registry and registrar if the variant model is 
> "you can have this variant on the condition that it is identical to 
> the primary name".

But of course, they're _not_ identical.  They're different names, and in Latin they might not even be labels that anyone would ever actually use (at least on purpose without fraudulent intent).

Best,

A

---

From: Benoit Levac <[email-masked]>
Date: Fri, 30 Mar 2012 08:42:35 -0400

Mike,

I would be interested in reviewing the draft for sure.  You could just send me a copy if it’s not quite ready for public review.

The EPP RFCs only define the offline processing at a high level.  There are some aspects that are not covered that bring up some questions.  You might have experience with these since you seem to have implemented this.

Does a pending status such as “pendingUpdate” imply “serverUpdateProhibited”?  RFC 5731 only mentions that they cannot be combined.  The issue we have to think about is that if a domain is in “pendingUpdate” status because a registrant update action is in progress, we wouldn’t want to prevent host updates for example if they are required.  This is mainly why we are asking about a standard means to cancel a pending actions.

Cheers,

Ben

From: mike [mailto:[email-masked]]
Sent: March-30-12 3:12 AM
To: Benoit Levac
Cc: [email-masked]
Subject: Re: [provreg] IDN administrative bundling

Hi Ben,

Kind Regards,

Mike

co.za

---

From: Luis Muñoz <[email-masked]>
Date: Fri, 30 Mar 2012 10:21:18 -0400

I for one would like to see that extension.

Thanks

-lem

mike <[email-masked]> wrote:

>We have a draft extension for cancelling pending actions on the
>registry, this allows the registrar to cancel a suspension, deletion,
>update, or deletion due to expiry by the action name. This creates some
>pretty complex policy handling esp. when expiry was due to non payment
>and cancelling that action results in billing. If you want a copy we
>can submit it for draft review.
>
>Kind Regards,
>
>Mike
>
>co.za_______________________________________________
>provreg mailing list
>[email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Fri, 30 Mar 2012 14:24:24 +0000

I see three different models for supporting the bundling of related
objects.  The concept of bundling could apply to domain names in a single
TLD, domain names across TLD's, and objects of different kinds within or
across TLD's.  

1. Validate sponsorship (registrar and registrant) only on create with no
sharing of attributes
     1. This was done in .name between different related objects (domain
names and email forwarding).
2. Ensure sponsorship (registrar and registrant) is always the same across
the related objects.
     1. Transform operations that impact the sponsorship would need to
apply the sponsorship changes across all of the related objects.  This can
be done explicitly in an EPP extension or implicitly.  I believe that for
transfer requests that it must be explicit since the gaining registrar
must be aware that an entire set is being transferred.  The update could
be implicit but probably should be explicit.
     2. One additional issue on the transfer request is passing the
non-shared auth-info value for each of the related objects to authorize
the transfer of each independent but related object.
     3. Another option is to use pending actions and have the registrar
use multiple transform operation across the related objects.  I believe
that this is overly complex from an interface perspective.
3. Ensure sponsorship (registrar and registrant) and other attributes is
the same (shared) across the related objects.
     1. This is the model chosen for IDN variants in
http://www.ietf.org/id/draft-kong-epp-idn-variants-mapping-00.txt.  All
attributes are shared across all of the related IDN domain names, where
the original IDN (OIDN) is the primary domain name and the remaining
variants are alternative domain names that can be activated and
deactivated but with the same attributes of the primary domain name
(OIDN).  
     2. I believe that it's best to utilize the RFC 5731 commands to
manage both the primary domain name (OIDN) and the alternative domain
names (VIDN), where some of the attributes can be shared and some either
can be or must not be shared.  The case of "must not be" is the DS
information of RFC 5910 when using the DS Data Interface.  An alternative
approach is to use the RFC 5910 Key Data Interface, that can be shared
across the related domain names, since the server would generate the DS
for each of the related domain names.
     3. An EPP extension is still required for informational and
validation purposes.
     4. As with model #2, the transfer request must be explicitly include
a reference to the entire bundle to ensure that the gaining registrar is
aware of the transfer of the set instead of an individual domain name.

--
  
JG

James Gould
Principal Software Engineer
[email-masked]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 30 Mar 2012 19:57:17 -0400

> TLD, domain names across TLD's, and objects of different kinds within or

I don't care what we call them, but I do not see how anyone can claim
that "bundling" in the same sense can cross domain (I'm almost tempted
to say "zone") boundaries and also be the narrow meaning often
intended by the word.

Bundling(n) [n for narrow] is a case where, within the same domain,
two subordinate labels are somehow treated as basically linked in some
way.  This is the meaning of bundling (and one of the meanings of
"variant") that has most traditionally been seen in the RFCs. The
links may be purely administrative, by which we mean that the
administrative details of the name are required to be the same; or
they may be technically tighter, such as a requirement for mirroring
(either via aliasing or administrative fiat of parallel delegation).
An example of this case is example.com and éxample.com: these are both
names in the same domain (and zone).

Bundling(w) [w for wide], which I would prefer to call "domain
linking" or something like that, is where two names in different parts
of the DNS namespace are somehow treated in ways that link them
together.  As above, these links may be stronger or weaker, but the
key is that they be in different domains.  If example.com and
example.net are somehow linked together, for instance, it would be a
case of this.

best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: James Mitchell <[email-masked]>
Date: Sat, 31 Mar 2012 16:11:07 +1100

You forget where the zone name also has variant names delegated from its parent zone.

---

From: James Mitchell <[email-masked]>
Date: Sat, 31 Mar 2012 19:56:07 +1100

After re-reading your message I both agree and disagree depending on the domain which you consider your point of reference.

If your point of reference is a domain with variant names then B(n) still holds for all subordinate names, however the domain's variant labels also fit in your definition of B(w).

In this case one can change their point of reference to the parent domain, however this is somewhat unnatural as one does not necessarily have administrative control the parent domain.

I'm not saying you are wrong, there are two distinct concepts as you describe but I believe your definitions could use some tightening. I agree the term bundling should probably not be used to describe the latter given its current usage.

James

On 31/03/2012, at 7:33 PM, "Andrew Sullivan" <[email-masked]> wrote:

> No, I don't. Delegations from the parent are names in a domain. They're case B(n) in what I wrote. 
> 
> -- 
> Andrew Sullivan 
> Please excuse my clumsy thumbs. 
> 
> On 2012-03-31, at 7:11, James Mitchell <[email-masked]> wrote:
>