Re: IDN administrative bundling

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 protected]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com







On 3/30/12 5:24 AM, "Andrew Sullivan" <[email protected]> wrote:

>On Fri, Mar 30, 2012 at 06:45:54PM +1100, James Mitchell wrote:
>> 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".
>
>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 protected]
>_______________________________________________
>provreg mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/provreg

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg