From nobody Fri May 9 07:08:06 2014 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525991A02BF for ; Fri, 9 May 2014 07:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNJ5_--kKaDg for ; Fri, 9 May 2014 07:07:40 -0700 (PDT) Received: from kmx10a.knipp.de (clust3a.bbone.knipp.de [195.253.6.83]) by ietfa.amsl.com (Postfix) with ESMTP id EA5421A02D9 for ; Fri, 9 May 2014 07:07:39 -0700 (PDT) Received: from localhost (localhost.bbone.knipp.de [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 3ECAF49; Fri, 9 May 2014 16:07:34 +0200 (MESZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id 7UW4V9yktif5; Fri, 9 May 2014 16:07:26 +0200 (MESZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id D1DCE4A; Fri, 9 May 2014 16:07:26 +0200 (MESZ) Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id s49E7QSi002222; Fri, 9 May 2014 16:07:26 +0200 (MESZ) Message-ID: <536CE129.4010004@knipp.de> Date: Fri, 09 May 2014 16:07:37 +0200 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Thunderbird/32.0a1 MIME-Version: 1.0 To: "ire@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ire/i58p-bbHOafeTNeihxcueMXcWLw Subject: [ire] question regarding IDN variant mapping, value X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 14:07:57 -0000 Hi all, my colleagues and I came across a specific problem regarding of the handling of IDN variants in escrows, and we did not find a clear answer in the specifications[1]. As you might know, there are basically two models of how to treat IDN variants: 1) as an attribute to a domain, i.e. variants are part of a single domain, the names are typically supplied via an EPP extension to the create and update commands. (example: .cat gTLD registry) 2) as separate domain objects, i.e. for each variant, separate create and delete commands have to be issued to add or remove them. The registry may restrict operations so that two variants can not be associated with two different registrants and so on. (example: .ca ccTLD registry) The specification provides an element (in the XML form, a respective field in the CSV form) to link these variants to each other, both for the domain objects and for the NNDNs. While the latter is quite suitable to represent the model described in 1), the first is likely intended for the model described in 2). The question now is, what does that field actually contain in the model 2)? Of course, a domain name, as the specification demands, but which one? If it would need to be one of the existing variants, this would become a problem on an incremental update. For example, if we have the variants A and B, and B would point to A in the : If A gets deleted, B remains factually unchanged, and would not be reported in an incremental escrow. When the data gets reconstructed (for example by an EBERO provider), the importer might find the reference to A, but not A itself, because its deletion was reported. Also, if a new domain C is registered that is a variant of A and B, it would likely point to B instead of the deleted domain A. This would also puzzle a potential importer. On the other hand, the specification does not clearly define that the name which is specified by needs to exist at all. One could declare one of the potential variants as a "generic", "canonical" variant, which is used for this field even if this variant itself is not registered. For example, if D would be this generic variant, and the variants A and B have been registered, they both would refer to D in the field. Thus, if either A or B gets deleted, nothing would break. An importer would simply group domain names that refer to the very same name, whatever this is. Any ideas, any opinions, any interpretations of the specs? This would be greatly helpful for us. Regards, Klaus [1] https://tools.ietf.org/html/draft-arias-noguchi-dnrd-objects-mapping-05 From nobody Fri May 9 11:41:10 2014 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD711A0076 for ; Fri, 9 May 2014 11:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xE5Ji93OaiT for ; Fri, 9 May 2014 11:41:05 -0700 (PDT) Received: from exprod6og125.obsmtp.com (exprod6og125.obsmtp.com [64.18.1.218]) by ietfa.amsl.com (Postfix) with ESMTP id 640161A0053 for ; Fri, 9 May 2014 11:41:00 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob125.postini.com ([64.18.5.12]) with SMTP ID DSNKU20hN1MKSPn6a6shWeIzK7FYlj3fNZXQ@postini.com; Fri, 09 May 2014 11:41:00 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s49IerUq011705 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 May 2014 14:40:54 -0400 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 9 May 2014 14:40:53 -0400 From: "Gould, James" To: Klaus Malorny , "ire@ietf.org" Thread-Topic: [ire] question regarding IDN variant mapping, value Thread-Index: AQHPa5AYJxQav2kLAEuW42npt1gQaZs4lTGA Date: Fri, 9 May 2014 18:40:52 +0000 Message-ID: In-Reply-To: <536CE129.4010004@knipp.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_CF9272125E7D4jgouldverisigncom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ire/vvTYcrsZq04Uk5s4LkKshgmiCSc Subject: Re: [ire] question regarding IDN variant mapping, value X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 18:41:08 -0000 --_000_CF9272125E7D4jgouldverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Klaus, As you point out the draft supports both models. For model #1 the NNDN Variant IDN (VIDN) would reference the Original IDN (= OIDN) using the element in XML or the field in CSV. I would assume that for model #1, since the variant is an= attribute of the OIDN, that all of the domain attributes are shared and th= at it=92s a containment relationship. Deleting the OIDN should result in t= he deletion of the related variants (VIDN=92s). For model #2 the VIDN is treated as a domain entity with the XML element or the CSV =93domain=94 file, with the relationship betwee= n the VIDN and the ODIN using the the element in XML or the = field in CSV. I still view this as containment re= lationship, where the VIDN's have independent attributes but are contained = under the OIDN. Deleting the OIDN should result in the deletion of the re= lated VIDN's. I cover your use cases below: If it would need to be one of the existing variants, this would become a pr= oblem on an incremental update. For example, if we have the variants A and B, and= B would point to A in the : If A gets deleted, B remains factua= lly unchanged, and would not be reported in an incremental escrow. When the dat= a gets reconstructed (for example by an EBERO provider), the importer might f= ind the reference to A, but not A itself, because its deletion was reported. Al= so, if a new domain C is registered that is a variant of A and B, it would like= ly point to B instead of the deleted domain A. This would also puzzle a potent= ial importer. I view A as the OIDN and B as the VIDN, where if A is deleted, B should als= o be deleted. There could be a pre-condition that VIDN's (B) be disabled o= r deleted prior to allowing the OIDN to get deleted. That means that no or= phan VIDN=92s should exist when deleting the OIDN. If deleting the OIDN de= letes all VIDN=92s then they would be deleted together. I would imagine th= at domain C would only be allowed as a VIDN of A. If not, I would need to = better understand the registry logic for variants. On the other hand, the specification does not clearly define that the name = which is specified by needs to exist at all. One could declare one= of the potential variants as a "generic", "canonical" variant, which is used f= or this field even if this variant itself is not registered. For example, if D would be this generic variant, and the variants A and B have been registere= d, they both would refer to D in the field. Thus, if either A o= r B gets deleted, nothing would break. An importer would simply group domain na= mes that refer to the very same name, whatever this is. Although the draft does not explicitly define that the must = exist, the existence of referenced entities should be expected throughout t= he draft. The same could be stated for the or references, but I believe it is expected that the referenced hosts or= contacts must already exist. I view the OIDN=92s to have a containment relationship with the VIDN=92s in= both your models, where the only difference is whether the domain attribut= es are shared. Thanks, -- JG James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 5/9/14, 10:07 AM, "Klaus Malorny" > wrote: Hi all, my colleagues and I came across a specific problem regarding of the handlin= g of IDN variants in escrows, and we did not find a clear answer in the specifications[1]. As you might know, there are basically two models of how to treat IDN varia= nts: 1) as an attribute to a domain, i.e. variants are part of a single domain= , the names are typically supplied via an EPP extension to the create and update commands. (example: .cat gTLD registry) 2) as separate domain objects, i.e. for each variant, separate create and delete commands have to be issued to add or remove them. The registry may restrict operations so that two variants can not be associated wit= h two different registrants and so on. (example: .ca ccTLD registry) The specification provides an element (in the XML form, a respective field in the CSV form) to link these variants to each other, bot= h for the domain objects and for the NNDNs. While the latter is quite suitable to represent the model described in 1), the first is likely intended for the m= odel described in 2). The question now is, what does that field actually contain in the model 2)?= Of course, a domain name, as the specification demands, but which one? If it would need to be one of the existing variants, this would become a pr= oblem on an incremental update. For example, if we have the variants A and B, and= B would point to A in the : If A gets deleted, B remains factua= lly unchanged, and would not be reported in an incremental escrow. When the dat= a gets reconstructed (for example by an EBERO provider), the importer might f= ind the reference to A, but not A itself, because its deletion was reported. Al= so, if a new domain C is registered that is a variant of A and B, it would like= ly point to B instead of the deleted domain A. This would also puzzle a potent= ial importer. On the other hand, the specification does not clearly define that the name = which is specified by needs to exist at all. One could declare one= of the potential variants as a "generic", "canonical" variant, which is used f= or this field even if this variant itself is not registered. For example, if D would be this generic variant, and the variants A and B have been registere= d, they both would refer to D in the field. Thus, if either A o= r B gets deleted, nothing would break. An importer would simply group domain na= mes that refer to the very same name, whatever this is. Any ideas, any opinions, any interpretations of the specs? This would be gr= eatly helpful for us. Regards, Klaus [1] https://tools.ietf.org/html/draft-arias-noguchi-dnrd-objects-mapping-05 _______________________________________________ ire mailing list ire@ietf.org https://www.ietf.org/mailman/listinfo/ire --_000_CF9272125E7D4jgouldverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Klaus,

As you point out the draft supports b= oth models.  

For model #1 the NNDN Variant IDN (VIDN) wo= uld reference the Original IDN (OIDN) using the <originalName> elemen= t in XML or the <csvDomain:fOrginalName> field in CSV.  I would = assume that for model #1, since the variant is an attribute of the OIDN, that all of the domain attributes are shared and that it=92s = a containment relationship.  Deleting the OIDN should result= in the deletion of the related variants (VIDN=92s). 

For model #2 the VIDN is treated as a domai= n entity with the <rdeDomain:domain> XML element or the CSV =93d= omain=94 file, with the relationship between the VIDN and the ODIN using th= e the <originalName> element in XML or the <csvDomain:fOrgina= lName> field in CSV.  I still view this as containment relationshi= p, where the VIDN's have independent attributes but are contained under &nb= sp;the OIDN.  Deleting the OIDN should result in the deletion of the r= elated VIDN's.   

I cover your use cases below:

If it would need to be one of the existing variants, this would become= a problem
on an incremental update. For example, if we have the variants A and B= , and B
would point to A in the <originalName>: If A gets deleted, B rem= ains factually
unchanged, and would not be reported in an incremental escrow. When th= e data
gets reconstructed (for example by an EBERO provider), the importer mi= ght find
the reference to A, but not A itself, because its deletion was reporte= d. Also,
if a new domain C is registered that is a variant of A and B, it would= likely
point to B instead of the deleted domain A. This would also puzzle a p= otential
importer.

I view A as the OIDN and B as the VIDN, where if A is deleted, B shoul= d also be deleted.  There could be a pre-condition that VIDN's (B) be = disabled or deleted prior to allowing the OIDN to get deleted.  That m= eans that no orphan VIDN=92s should exist when deleting the OIDN.  If deleting the OIDN deletes all VIDN=92s then th= ey would be deleted together.  I would imagine that domain C would onl= y be allowed as a VIDN of A.  If not, I would need to better understan= d the registry logic for variants.  

On the other hand, the specification does not clearly define that the = name which
is specified by <originalName> needs to exist at all. One could = declare one of
the potential variants as a "generic", "canonical"= variant, which is used for
this field even if this variant itself is not registered. For example,= if D
would be this generic variant, and the variants A and B have been regi= stered,
they both would refer to D in the <originalName> field. Thus, if= either A or B
gets deleted, nothing would break. An importer would simply group doma= in names
that refer to the very same name, whatever this is.

Although the draft does not explicitly defi= ne that the <originalName> must exist, the existence of referenced en= tities should be expected throughout the draft.  The same could be sta= ted for the <domain:hostObj> or <rdeDom:contact> references, but I believe it is expected that the referenced hosts or cont= acts must already exist.  

I view the OIDN=92s to have a containment r= elationship with the VIDN=92s in both your models, where the only differenc= e is whether the domain attributes are shared.

Thanks,

-- 
 
JG
 

 
James Gould
Principal Software Engineer
jgould@verisign.com
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com



On 5/9/14= , 10:07 AM, "Klaus Malorny" <Klaus.Malorny@knipp.de> wrote:



Hi all,

my colleagues and I came across a specific problem regarding of the ha= ndling of
IDN variants in escrows, and we did not find a clear answer in the
specifications[1].

As you might know, there are basically two models of how to treat IDN = variants:

  1) as an attribute to a domain, i.e. variants are part of = a single domain,
     the names are typically supplied via an EPP e= xtension to the create
     and update commands. (example: .cat gTLD regi= stry)

  2) as separate domain objects, i.e. for each variant, sepa= rate create and
     delete commands have to be issued to add or r= emove them. The registry
     may restrict operations so that two variants = can not be associated with two
     different registrants and so on. (example: .c= a ccTLD registry)

The specification provides an <originalName> element (in the XML= form, a
respective field in the CSV form) to link these variants to each other= , both for
the domain objects and for the NNDNs. While the latter is quite suitab= le to
represent the model described in 1), the first is likely intended for = the model
described in 2).

The question now is, what does that field actually contain in the mode= l 2)? Of
course, a domain name, as the specification demands, but which one?

If it would need to be one of the existing variants, this would become= a problem
on an incremental update. For example, if we have the variants A and B= , and B
would point to A in the <originalName>: If A gets deleted, B rem= ains factually
unchanged, and would not be reported in an incremental escrow. When th= e data
gets reconstructed (for example by an EBERO provider), the importer mi= ght find
the reference to A, but not A itself, because its deletion was reporte= d. Also,
if a new domain C is registered that is a variant of A and B, it would= likely
point to B instead of the deleted domain A. This would also puzzle a p= otential
importer.

On the other hand, the specification does not clearly define that the = name which
is specified by <originalName> needs to exist at all. One could = declare one of
the potential variants as a "generic", "canonical"= variant, which is used for
this field even if this variant itself is not registered. For example,= if D
would be this generic variant, and the variants A and B have been regi= stered,
they both would refer to D in the <originalName> field. Thus, if= either A or B
gets deleted, nothing would break. An importer would simply group doma= in names
that refer to the very same name, whatever this is.

Any ideas, any opinions, any interpretations of the specs? This would = be greatly
helpful for us.

Regards,

Klaus





_______________________________________________
ire mailing list

--_000_CF9272125E7D4jgouldverisigncom_-- From nobody Sat May 10 04:06:50 2014 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A534C1A0217 for ; Sat, 10 May 2014 04:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pasfhlZ0toi for ; Sat, 10 May 2014 04:06:44 -0700 (PDT) Received: from kmx10a.knipp.de (clust3a.bbone.knipp.de [195.253.6.83]) by ietfa.amsl.com (Postfix) with ESMTP id EFA1F1A021B for ; Sat, 10 May 2014 04:06:42 -0700 (PDT) Received: from localhost (localhost.bbone.knipp.de [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 111F657; Sat, 10 May 2014 13:06:36 +0200 (MESZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id 9KLThT1oBLny; Sat, 10 May 2014 13:06:27 +0200 (MESZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 8149F50; Sat, 10 May 2014 13:06:27 +0200 (MESZ) Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id s4AB6Qdl019202; Sat, 10 May 2014 13:06:26 +0200 (MESZ) Message-ID: <536E083D.90409@knipp.de> Date: Sat, 10 May 2014 13:06:37 +0200 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Thunderbird/32.0a1 MIME-Version: 1.0 To: "Gould, James" , "ire@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/ire/PwkdcjWAlgYsJU5wTvcheot7Vrs Subject: Re: [ire] question regarding IDN variant mapping, value X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 11:06:46 -0000 On 09.05.2014 20:40, Gould, James wrote: > Klaus, > Hi James, thanks for answering. > > I view A as the OIDN and B as the VIDN, where if A is deleted, B should= also be > deleted. There could be a pre-condition that VIDN's (B) be disabled or= deleted > prior to allowing the OIDN to get deleted. That means that no orphan V= IDN=92s > should exist when deleting the OIDN. If deleting the OIDN deletes all = VIDN=92s > then they would be deleted together. I would imagine that domain C wou= ld only > be allowed as a VIDN of A. If not, I would need to better understand t= he > registry logic for variants. But why this restriction? The advantage of the "object model" over the=20 "attribute model" is -- besides the ability to have different name server= s=20 and/or DNSSEC data -- that you only have a loose bundling. Also, in some = scripts, you don't have a variant that is "original". If you have two var= iants=20 which have equal value, what makes the one the "original" and the other n= ot? For=20 example, we have this situation with the Chinese traditional and simplifi= ed=20 ideographs and also with Arabic letters. Why should a registrant, who has= =20 registered A at first and then B, shall not be able to give up variant A = at a=20 later point in time, while keeping variant B? Maybe I miss something, but while I think it is at a registry's discretio= n to=20 use a policy as you describe, I do not see neither technical nor procedur= al or=20 legal needs for such constraints. > Although the draft does not explicitly define that the m= ust > exist, the existence of referenced entities should be expected througho= ut the > draft. The same could be stated for the or > references, but I believe it is expected that the referenced hosts or c= ontacts > must already exist. > > I view the OIDN=92s to have a containment relationship with the VIDN=92= s in both > your models, where the only difference is whether the domain attributes= are shared. I think it is not within the authority of the escrow format to enforce su= ch a=20 policy. I therefore propose to define the as follows: 1) The "original name" is a FQDN (as defined in the draft). 2) The "original name" identifies a group of domain names that are considered to be variants of each other. 3) The "original name" does not need to refer to an existing domain ob= ject. 4) If the "original name" is not given with a domain, it is implicitly= the name of the domain. This rule does not apply to NNDNs. Rule 4) assures the compatibility to registry models where a "primus inte= r=20 pares" exists (i.e. the OIDN in your description) and the "original name"= is not=20 generated in escrows for these objects. > JG > Regards, Klaus From nobody Mon May 12 06:12:56 2014 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C623A1A0699 for ; Mon, 12 May 2014 06:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4Rxo6jAZa1O for ; Mon, 12 May 2014 06:12:35 -0700 (PDT) Received: from exprod6og118.obsmtp.com (exprod6og118.obsmtp.com [64.18.1.233]) by ietfa.amsl.com (Postfix) with ESMTP id 945D51A031E for ; Mon, 12 May 2014 06:12:33 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob118.postini.com ([64.18.5.12]) with SMTP ID DSNKU3DIuwBkhyDLEjNE02CpPPwjoWkUpxA/@postini.com; Mon, 12 May 2014 06:12:29 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s4CDCRFv016732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 May 2014 09:12:27 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 12 May 2014 09:12:27 -0400 From: "Gould, James" To: Klaus Malorny , "ire@ietf.org" Thread-Topic: [ire] question regarding IDN variant mapping, value Thread-Index: AQHPa5AYJxQav2kLAEuW42npt1gQaZs4lTGAgAFWj4CAAwUEgA== Date: Mon, 12 May 2014 13:12:26 +0000 Message-ID: In-Reply-To: <536E083D.90409@knipp.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <77773DE5DBDB5A4BA99FE2C5D5B9D70D@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ire/1Am_rVhGYyeZpDHjRGQQuG8SGJ8 Subject: Re: [ire] question regarding IDN variant mapping, value X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 13:12:47 -0000 Klaus, My feedback is embedded below. --=20 =20 JG =20 =20 James Gould Principal Software Engineer jgould@verisign.com =20 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 5/10/14, 7:06 AM, "Klaus Malorny" wrote: >On 09.05.2014 20:40, Gould, James wrote: >> Klaus, >> > >Hi James, > >thanks for answering. > >> >> I view A as the OIDN and B as the VIDN, where if A is deleted, B should >>also be >> deleted. There could be a pre-condition that VIDN's (B) be disabled or >>deleted >> prior to allowing the OIDN to get deleted. That means that no orphan >>VIDN=B9s >> should exist when deleting the OIDN. If deleting the OIDN deletes all >>VIDN=B9s >> then they would be deleted together. I would imagine that domain C >>would only >> be allowed as a VIDN of A. If not, I would need to better understand >>the >> registry logic for variants. > >But why this restriction? The advantage of the "object model" over the >"attribute model" is -- besides the ability to have different name >servers=20 >and/or DNSSEC data -- that you only have a loose bundling. Also, in some >scripts, you don't have a variant that is "original". If you have two >variants=20 >which have equal value, what makes the one the "original" and the other >not? For=20 >example, we have this situation with the Chinese traditional and >simplified=20 >ideographs and also with Arabic letters. Why should a registrant, who has >registered A at first and then B, shall not be able to give up variant A >at a=20 >later point in time, while keeping variant B? > >Maybe I miss something, but while I think it is at a registry's >discretion to=20 >use a policy as you describe, I do not see neither technical nor >procedural or=20 >legal needs for such constraints. The data escrow needs to reflect the possible set of data models, where the only known model for related variants is a one-to-many relationship of OIDN to VIDN=B9s as reflected in draft-kong-epp-idn-variants-mapping ( http://tools.ietf.org/html/draft-kong-epp-idn-variants-mapping ) with different levels of sharing (share all in your model #1 and NNDN, or share none or some in your model #2 and separate objects). What you are referring to is a different model that reflects a many-to-many relationship with no concept of an OIDN, since all of the variants are sibling objects (A, B, and C are related to each other with no hierarchy). I=B9m assuming that in your data model that you have some form of a link table to reflect the relationship. Are all related variants authorized to a single registrant? Does your system need to ensure that any of the attributes remain the same, like the registrar and registrant, across the related variants? From an EPP perspective, do you have a custom EPP extension to reflect the related variants, and if so can you reference it to help clarify things? > >> Although the draft does not explicitly define that the >>must >> exist, the existence of referenced entities should be expected >>throughout the >> draft. The same could be stated for the or >> >> references, but I believe it is expected that the referenced hosts or >>contacts >> must already exist. >> >> I view the OIDN=B9s to have a containment relationship with the VIDN=B9s= in >>both >> your models, where the only difference is whether the domain attributes >>are shared. > >I think it is not within the authority of the escrow format to enforce >such a=20 >policy. I therefore propose to define the as follows: > > 1) The "original name" is a FQDN (as defined in the draft). > 2) The "original name" identifies a group of domain names that are > considered to be variants of each other. > 3) The "original name" does not need to refer to an existing domain >object. > 4) If the "original name" is not given with a domain, it is implicitly >the > name of the domain. This rule does not apply to NNDNs. The data escrow is a representation of a data model, and it only makes sense to ensure that all object references exist. Your proposed language change defines a new variant group entity or tag that does not match the existing supported data model. To support your data model of a many-to-many relationship, a new entity (or tag) "variant group" would need to be defined. Instead of using the element to refer to a domain object (OIDN), something like would be needed to reference a variant group entity or be used to tag the variant group string. If is a reference to an actual entity with attributes, I=B9m assuming that the variant group entity would be removed once all variant references are removed. Are there other registries out there that support a many-to-many relationship for variants? > >Rule 4) assures the compatibility to registry models where a "primus >inter=20 >pares" exists (i.e. the OIDN in your description) and the "original name" >is not=20 >generated in escrows for these objects. > >> JG >> > >Regards, > >Klaus > > From nobody Mon May 12 09:13:38 2014 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E10101A034E for ; Mon, 12 May 2014 09:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMsqCnKlcgO1 for ; Mon, 12 May 2014 09:13:32 -0700 (PDT) Received: from kmx10a.knipp.de (clust3a.bbone.knipp.de [195.253.6.83]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB421A033E for ; Mon, 12 May 2014 09:13:32 -0700 (PDT) Received: from localhost (localhost.bbone.knipp.de [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 268F74D; Mon, 12 May 2014 18:13:25 +0200 (MESZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id D+SdzP4XxnVT; Mon, 12 May 2014 18:13:18 +0200 (MESZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id B4B704C; Mon, 12 May 2014 18:13:18 +0200 (MESZ) Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id s4CGDHe2029630; Mon, 12 May 2014 18:13:17 +0200 (MESZ) Message-ID: <53710F30.3010500@knipp.de> Date: Mon, 12 May 2014 20:13:04 +0200 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Thunderbird/32.0a1 MIME-Version: 1.0 To: "Gould, James" , "ire@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/ire/rr4KL-UMf7jilkAuf-tjl1F-pFA Subject: Re: [ire] question regarding IDN variant mapping, value X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 16:13:35 -0000 On 12.05.2014 15:12, Gould, James wrote: > Klaus, > > My feedback is embedded below. > Hi James, > The data escrow needs to reflect the possible set of data models, where= > the only known model for related variants is a one-to-many relationship= of > OIDN to VIDN=B9s as reflected in draft-kong-epp-idn-variants-mapping ( > http://tools.ietf.org/html/draft-kong-epp-idn-variants-mapping ) with > different levels of sharing (share all in your model #1 and NNDN, or sh= are > none or some in your model #2 and separate objects). Well, to my knowledge, registries are not bound to data models that are=20 published as RFCs or expired drafts ;-). Also, the Kong mapping is clearl= y an=20 implementation of model #1, and this assumes that the OIDN remains consta= nt --=20 otherwise, a domain "rename" would have to be implemented, like this can = be done=20 for the hosts. While this is not impossible, I haven't seen this in the w= ild... > What you are > referring to is a different model that reflects a many-to-many > relationship with no concept of an OIDN, since all of the variants are > sibling objects (A, B, and C are related to each other with no hierarch= y). Yes -- more or less -- as this is a matter of definition. > I=B9m assuming that in your data model that you have some form of a li= nk > table to reflect the relationship. This is still in the planning phase, however, there is no dedicated objec= t or=20 attribute whatever planned that is publicly visible. > Are all related variants authorized to > a single registrant? Does your system need to ensure that any of the > attributes remain the same, like the registrar and registrant, across t= he > related variants? Yes, contacts need to be the same, and this constraint is enforced after = the=20 creation of the variants. You can take the Canadian registry (CIRA) as a = prototype. > From an EPP perspective, do you have a custom EPP > extension to reflect the related variants, and if so can you reference = it > to help clarify things? Yes, there will be an extension, but it will only occur in responses, not= in=20 commands. > The data escrow is a representation of a data model, and it only makes > sense to ensure that all object references exist. Your proposed langua= ge > change defines a new variant group entity or tag that does not match th= e > existing supported data model. To support your data model of a > many-to-many relationship, a new entity (or tag) "variant group" would > need to be defined. Instead of using the element to ref= er > to a domain object (OIDN), something like would be neede= d > to reference a variant group entity or be used to tag the variant group= > string. If is a reference to an actual entity with > attributes, I=B9m assuming that the variant group entity would be remov= ed > once all variant references are removed. Are there other registries out= > there that support a many-to-many relationship for variants? The proposal to concretize the attribute in a manner that = is=20 compatible with our intended/the French model was simply meant to keep th= e=20 effort low. I don't mind adding a new attribute of whatever name to the e= scrow=20 format if this is considered the better way. However, I would like to avo= id a=20 separate new object type to which the "variantGroup" attribute is referri= ng.=20 Simply take it as the "city names on the map of domain names", figurative= ly=20 spoken ;-) -- you won't link contact objects of persons living the same c= ity to=20 a "city" object in the escrow, just because they share that property... Regards, Klaus From nobody Mon May 12 10:52:23 2014 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651AD1A077C for ; Mon, 12 May 2014 10:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeN8duxGuJOY for ; Mon, 12 May 2014 10:52:18 -0700 (PDT) Received: from exprod6og119.obsmtp.com (exprod6og119.obsmtp.com [64.18.1.234]) by ietfa.amsl.com (Postfix) with ESMTP id DAF401A0745 for ; Mon, 12 May 2014 10:52:14 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob119.postini.com ([64.18.5.12]) with SMTP ID DSNKU3EKSNkGXQN18By0j1XPaT54BmCVPgYI@postini.com; Mon, 12 May 2014 10:52:10 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s4CHq8a1019744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 May 2014 13:52:08 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 12 May 2014 13:52:07 -0400 From: "Gould, James" To: Klaus Malorny , "ire@ietf.org" Thread-Topic: [ire] question regarding IDN variant mapping, value Thread-Index: AQHPa5AYJxQav2kLAEuW42npt1gQaZs4lTGAgAFWj4CAAwUEgIAAlswA//+3ToA= Date: Mon, 12 May 2014 17:52:06 +0000 Message-ID: In-Reply-To: <53710F30.3010500@knipp.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ire/0Dzdhf7aP3XQl5fkykGbLrpAbIk Subject: Re: [ire] question regarding IDN variant mapping, value X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 17:52:21 -0000 S2xhdXMsDQoNCk15IGZlZWRiYWNrIGlzIGJlbG93Lg0KDQotLSANCiANCkpHDQogDQoNCiANCkph bWVzIEdvdWxkDQpQcmluY2lwYWwgU29mdHdhcmUgRW5naW5lZXINCmpnb3VsZEB2ZXJpc2lnbi5j b20NCiANCjcwMy05NDgtMzI3MSAoT2ZmaWNlKQ0KMTIwNjEgQmx1ZW1vbnQgV2F5DQpSZXN0b24s IFZBIDIwMTkwDQpWZXJpc2lnbkluYy5jb20NCg0KDQoNCg0KT24gNS8xMi8xNCwgMjoxMyBQTSwg IktsYXVzIE1hbG9ybnkiIDxLbGF1cy5NYWxvcm55QGtuaXBwLmRlPiB3cm90ZToNCg0KPk9uIDEy LjA1LjIwMTQgMTU6MTIsIEdvdWxkLCBKYW1lcyB3cm90ZToNCj4+IEtsYXVzLA0KPj4NCj4+IE15 IGZlZWRiYWNrIGlzIGVtYmVkZGVkIGJlbG93Lg0KPj4NCj4NCj5IaSBKYW1lcywNCj4NCj4+IFRo ZSBkYXRhIGVzY3JvdyBuZWVkcyB0byByZWZsZWN0IHRoZSBwb3NzaWJsZSBzZXQgb2YgZGF0YSBt b2RlbHMsIHdoZXJlDQo+PiB0aGUgb25seSBrbm93biBtb2RlbCBmb3IgcmVsYXRlZCB2YXJpYW50 cyBpcyBhIG9uZS10by1tYW55IHJlbGF0aW9uc2hpcA0KPj5vZg0KPj4gT0lETiB0byBWSUROqfZz IGFzIHJlZmxlY3RlZCBpbiBkcmFmdC1rb25nLWVwcC1pZG4tdmFyaWFudHMtbWFwcGluZyAoDQo+ PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1rb25nLWVwcC1pZG4tdmFyaWFudHMt bWFwcGluZyApIHdpdGgNCj4+IGRpZmZlcmVudCBsZXZlbHMgb2Ygc2hhcmluZyAoc2hhcmUgYWxs IGluIHlvdXIgbW9kZWwgIzEgYW5kIE5ORE4sIG9yDQo+PnNoYXJlDQo+PiBub25lIG9yIHNvbWUg aW4geW91ciBtb2RlbCAjMiBhbmQgc2VwYXJhdGUgb2JqZWN0cykuDQo+DQo+V2VsbCwgdG8gbXkg a25vd2xlZGdlLCByZWdpc3RyaWVzIGFyZSBub3QgYm91bmQgdG8gZGF0YSBtb2RlbHMgdGhhdCBh cmUNCj5wdWJsaXNoZWQgYXMgUkZDcyBvciBleHBpcmVkIGRyYWZ0cyA7LSkuIEFsc28sIHRoZSBL b25nIG1hcHBpbmcgaXMNCj5jbGVhcmx5IGFuIA0KPmltcGxlbWVudGF0aW9uIG9mIG1vZGVsICMx LCBhbmQgdGhpcyBhc3N1bWVzIHRoYXQgdGhlIE9JRE4gcmVtYWlucw0KPmNvbnN0YW50IC0tIA0K Pm90aGVyd2lzZSwgYSBkb21haW4gInJlbmFtZSIgd291bGQgaGF2ZSB0byBiZSBpbXBsZW1lbnRl ZCwgbGlrZSB0aGlzIGNhbg0KPmJlIGRvbmUgDQo+Zm9yIHRoZSBob3N0cy4gV2hpbGUgdGhpcyBp cyBub3QgaW1wb3NzaWJsZSwgSSBoYXZlbid0IHNlZW4gdGhpcyBpbiB0aGUNCj53aWxkLi4uDQoN CkkgZGlkbqGvdCBpbXBseSB0aGF0IHRoZSByZWdpc3RyaWVzIGFyZSBib3VuZCB0byB0aGUgT0lE TiBhbmQgVklETidzIGRhdGENCm1vZGVsIG9mIGRyYWZ0LWtvbmctaWRuLXZhcmlhbnRzLW1hcHBp bmcsIGJ1dCB0aGF0IGEgb25lLXRvLW1hbnkNCnJlbGF0aW9uc2hpcCB3YXMgdGhlIG9ubHkga25v d24gcmVsYXRpb25zaGlwIGZvciB2YXJpYW50cy4gIEhhdmluZyBhDQpwcmltYXJ5IE9JRE4gdGhh dCB2YXJpYW50cyBhcmUgZW5hYmxlZCAvIGRpc2FibGVkIGZyb20gaXMgbm90IGFzIGNvbXBsZXgs DQpidXQgaXQgaXMgY2VydGFpbmx5IGxlc3MgZmxleGlibGUuDQoNCj4NCj4+IFdoYXQgeW91IGFy ZQ0KPj4gcmVmZXJyaW5nIHRvIGlzIGEgZGlmZmVyZW50IG1vZGVsIHRoYXQgcmVmbGVjdHMgYSBt YW55LXRvLW1hbnkNCj4+IHJlbGF0aW9uc2hpcCB3aXRoIG5vIGNvbmNlcHQgb2YgYW4gT0lETiwg c2luY2UgYWxsIG9mIHRoZSB2YXJpYW50cyBhcmUNCj4+IHNpYmxpbmcgb2JqZWN0cyAoQSwgQiwg YW5kIEMgYXJlIHJlbGF0ZWQgdG8gZWFjaCBvdGhlciB3aXRoIG5vDQo+PmhpZXJhcmNoeSkuDQo+ DQo+WWVzIC0tIG1vcmUgb3IgbGVzcyAtLSBhcyB0aGlzIGlzIGEgbWF0dGVyIG9mIGRlZmluaXRp b24uDQo+DQo+PiAgSan2bSBhc3N1bWluZyB0aGF0IGluIHlvdXIgZGF0YSBtb2RlbCB0aGF0IHlv dSBoYXZlIHNvbWUgZm9ybSBvZiBhIGxpbmsNCj4+IHRhYmxlIHRvIHJlZmxlY3QgdGhlIHJlbGF0 aW9uc2hpcC4NCj4NCj5UaGlzIGlzIHN0aWxsIGluIHRoZSBwbGFubmluZyBwaGFzZSwgaG93ZXZl ciwgdGhlcmUgaXMgbm8gZGVkaWNhdGVkDQo+b2JqZWN0IG9yIA0KPmF0dHJpYnV0ZSB3aGF0ZXZl ciBwbGFubmVkIHRoYXQgaXMgcHVibGljbHkgdmlzaWJsZS4NCj4NCj4+ICBBcmUgYWxsIHJlbGF0 ZWQgdmFyaWFudHMgYXV0aG9yaXplZCB0bw0KPj4gYSBzaW5nbGUgcmVnaXN0cmFudD8gIERvZXMg eW91ciBzeXN0ZW0gbmVlZCB0byBlbnN1cmUgdGhhdCBhbnkgb2YgdGhlDQo+PiBhdHRyaWJ1dGVz IHJlbWFpbiB0aGUgc2FtZSwgbGlrZSB0aGUgcmVnaXN0cmFyIGFuZCByZWdpc3RyYW50LCBhY3Jv c3MNCj4+dGhlDQo+PiByZWxhdGVkIHZhcmlhbnRzPw0KPg0KPlllcywgY29udGFjdHMgbmVlZCB0 byBiZSB0aGUgc2FtZSwgYW5kIHRoaXMgY29uc3RyYWludCBpcyBlbmZvcmNlZCBhZnRlcg0KPnRo ZSANCj5jcmVhdGlvbiBvZiB0aGUgdmFyaWFudHMuIFlvdSBjYW4gdGFrZSB0aGUgQ2FuYWRpYW4g cmVnaXN0cnkgKENJUkEpIGFzIGENCj5wcm90b3R5cGUuDQoNCldoZW4gY2hhbmdpbmcgdGhlIHJl Z2lzdHJhbnQgKHVwZGF0ZSkgb3IgcmVnaXN0cmFyICh0cmFuc2ZlciksIGRvZXMgdGhlDQplbnRp cmUgZ3JvdXAgb2YgdmFyaWFudHMgZ2V0IHVwZGF0ZWQgYXQgb25jZT8NCg0KPg0KPj4gIEZyb20g YW4gRVBQIHBlcnNwZWN0aXZlLCBkbyB5b3UgaGF2ZSBhIGN1c3RvbSBFUFANCj4+IGV4dGVuc2lv biB0byByZWZsZWN0IHRoZSByZWxhdGVkIHZhcmlhbnRzLCBhbmQgaWYgc28gY2FuIHlvdSByZWZl cmVuY2UNCj4+aXQNCj4+IHRvIGhlbHAgY2xhcmlmeSB0aGluZ3M/DQo+DQo+WWVzLCB0aGVyZSB3 aWxsIGJlIGFuIGV4dGVuc2lvbiwgYnV0IGl0IHdpbGwgb25seSBvY2N1ciBpbiByZXNwb25zZXMs IG5vdA0KPmluIA0KPmNvbW1hbmRzLg0KPg0KPj4gVGhlIGRhdGEgZXNjcm93IGlzIGEgcmVwcmVz ZW50YXRpb24gb2YgYSBkYXRhIG1vZGVsLCBhbmQgaXQgb25seSBtYWtlcw0KPj4gc2Vuc2UgdG8g ZW5zdXJlIHRoYXQgYWxsIG9iamVjdCByZWZlcmVuY2VzIGV4aXN0LiAgWW91ciBwcm9wb3NlZA0K Pj5sYW5ndWFnZQ0KPj4gY2hhbmdlIGRlZmluZXMgYSBuZXcgdmFyaWFudCBncm91cCBlbnRpdHkg b3IgdGFnIHRoYXQgZG9lcyBub3QgbWF0Y2ggdGhlDQo+PiBleGlzdGluZyBzdXBwb3J0ZWQgZGF0 YSBtb2RlbC4gIFRvIHN1cHBvcnQgeW91ciBkYXRhIG1vZGVsIG9mIGENCj4+IG1hbnktdG8tbWFu eSByZWxhdGlvbnNoaXAsIGEgbmV3IGVudGl0eSAob3IgdGFnKSAidmFyaWFudCBncm91cCIgd291 bGQNCj4+IG5lZWQgdG8gYmUgZGVmaW5lZC4gIEluc3RlYWQgb2YgdXNpbmcgdGhlIDxvcmlnaW5h bE5hbWU+IGVsZW1lbnQgdG8NCj4+cmVmZXINCj4+IHRvIGEgZG9tYWluIG9iamVjdCAoT0lETiks IHNvbWV0aGluZyBsaWtlIDx2YXJpYW50R3JvdXA+IHdvdWxkIGJlIG5lZWRlZA0KPj4gdG8gcmVm ZXJlbmNlIGEgdmFyaWFudCBncm91cCBlbnRpdHkgb3IgYmUgdXNlZCB0byB0YWcgdGhlIHZhcmlh bnQgZ3JvdXANCj4+IHN0cmluZy4gIElmIDx2YXJpYW50R3JvdXA+IGlzIGEgcmVmZXJlbmNlIHRv IGFuIGFjdHVhbCBlbnRpdHkgd2l0aA0KPj4gYXR0cmlidXRlcywgSan2bSBhc3N1bWluZyB0aGF0 IHRoZSB2YXJpYW50IGdyb3VwIGVudGl0eSB3b3VsZCBiZSByZW1vdmVkDQo+PiBvbmNlIGFsbCB2 YXJpYW50IHJlZmVyZW5jZXMgYXJlIHJlbW92ZWQuIEFyZSB0aGVyZSBvdGhlciByZWdpc3RyaWVz IG91dA0KPj4gdGhlcmUgdGhhdCBzdXBwb3J0IGEgbWFueS10by1tYW55IHJlbGF0aW9uc2hpcCBm b3IgdmFyaWFudHM/DQo+DQo+VGhlIHByb3Bvc2FsIHRvIGNvbmNyZXRpemUgdGhlIDxvcmlnaW5h bE5hbWU+IGF0dHJpYnV0ZSBpbiBhIG1hbm5lciB0aGF0DQo+aXMgDQo+Y29tcGF0aWJsZSB3aXRo IG91ciBpbnRlbmRlZC90aGUgRnJlbmNoIG1vZGVsIHdhcyBzaW1wbHkgbWVhbnQgdG8ga2VlcA0K PnRoZSANCj5lZmZvcnQgbG93LiBJIGRvbid0IG1pbmQgYWRkaW5nIGEgbmV3IGF0dHJpYnV0ZSBv ZiB3aGF0ZXZlciBuYW1lIHRvIHRoZQ0KPmVzY3JvdyANCj5mb3JtYXQgaWYgdGhpcyBpcyBjb25z aWRlcmVkIHRoZSBiZXR0ZXIgd2F5LiBIb3dldmVyLCBJIHdvdWxkIGxpa2UgdG8NCj5hdm9pZCBh IA0KPnNlcGFyYXRlIG5ldyBvYmplY3QgdHlwZSB0byB3aGljaCB0aGUgInZhcmlhbnRHcm91cCIg YXR0cmlidXRlIGlzDQo+cmVmZXJyaW5nLiANCj5TaW1wbHkgdGFrZSBpdCBhcyB0aGUgImNpdHkg bmFtZXMgb24gdGhlIG1hcCBvZiBkb21haW4gbmFtZXMiLA0KPmZpZ3VyYXRpdmVseSANCj5zcG9r ZW4gOy0pIC0tIHlvdSB3b24ndCBsaW5rIGNvbnRhY3Qgb2JqZWN0cyBvZiBwZXJzb25zIGxpdmlu ZyB0aGUgc2FtZQ0KPmNpdHkgdG8gDQo+YSAiY2l0eSIgb2JqZWN0IGluIHRoZSBlc2Nyb3csIGp1 c3QgYmVjYXVzZSB0aGV5IHNoYXJlIHRoYXQgcHJvcGVydHkuLi4NCg0KSWYgdGhlIG1hbnktdG8t bWFueSByZWxhdGlvbnNoaXAgZG9lcyBub3QgaGF2ZSBhbnkgYWRkaXRpb25hbCBhdHRyaWJ1dGVz DQp0aGF0IG5lZWQgdG8gYmUgZGVwb3NpdGVkLCB0aGVuIDx2YXJpYW50R3JvdXA+IGNvdWxkIGJl IGEgc2ltcGxlIGRhdGEgdHlwZQ0KKHRva2VuKSB0aGF0IGlzIGEgdGFnIGZvciB0aGUgdmFyaWFu dCBncm91cCB3aXRob3V0IGFueSBsaW5rYWdlIHRvIGFuDQplbnRpdHkgLyBvYmplY3QuICBJdKGv cyBiZXN0IHRvIGxlYXZlIHRoZSBpbnRlbnQgYW5kIG1lYW5pbmcgb2YNCjxvcmlnaW5hbE5hbWU+ IGFzIGlzIGFuZCBzaW1wbHkgYWRkIGEgbmV3IGVsZW1lbnQgdG8gaGFuZGxlIHRoaXMgY2FzZS4N ClRoZSBDU1YgbW9kZWwgd291bGQgYWRkIHRoZSBjb3JyZXNwb25kaW5nIG9wdGlvbmFsDQo8Y3N2 RG9tYWluOmZWYXJpYW50R3JvdXA+IGFuZCA8Y3N2Tk5ETjpmVmFyaWFudEdyb3VwPiBlbGVtZW50 cy4gIERvZXMgdGhpcw0Kd29yayBmb3IgeW91PyAgDQoNCj4NCj4NCj5SZWdhcmRzLA0KPg0KPkts YXVzDQo+DQo+DQo+DQo+DQo+DQo+DQoNCg== From nobody Tue May 13 05:34:19 2014 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65191A0092 for ; Tue, 13 May 2014 05:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8LRb_5iE9g6 for ; Tue, 13 May 2014 05:34:16 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id 75AE31A0088 for ; Tue, 13 May 2014 05:34:15 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKU3IRQfv14rzhZp9KJl9M9tjvkx6tjBxF@postini.com; Tue, 13 May 2014 05:34:09 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s4DCY8WH022657 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 13 May 2014 08:34:08 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 13 May 2014 08:34:08 -0400 From: "Gould, James" To: "ire@ietf.org" Thread-Topic: Support for Launch Applications and Claims in draft-arias-noguchi-dnrd-objects-mapping Thread-Index: AQHPbqeh+FHFbhb8YEaYU2K37b+xPw== Date: Tue, 13 May 2014 12:34:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_CF9789B85EC52jgouldverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ire/kIriTRIrL-H4qKRSC5baBzwJC2Y Subject: [ire] Support for Launch Applications and Claims in draft-arias-noguchi-dnrd-objects-mapping X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 12:34:17 -0000 --_004_CF9789B85EC52jgouldverisigncom_ Content-Type: multipart/alternative; boundary="_000_CF9789B85EC52jgouldverisigncom_" --_000_CF9789B85EC52jgouldverisigncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgd2FzIGJyb3VnaHQgdG8gbXkgYXR0ZW50aW9uIGEgbGl0dGxlIHdoaWxlIGJhY2sgdGhhdCBh IHJlZ2lzdHJ5IHdhcyBoYXZpbmcgZGlmZmljdWx0eSBkZXBvc2l0aW5nIGxhdW5jaCBhcHBsaWNh dGlvbnMgdXNpbmcgdGhlIENTViBtb2RlbCBvZiBkcmFmdC1hcmlhcy1ub2d1Y2hpLWRucmQtb2Jq ZWN0cy1tYXBwaW5nLCBzaW5jZSB0aGUgcHJpbWFyeSBrZXkgb2YgdGhlIENTViBmaWxlcyBpcyB0 aGUgZG9tYWluIG5hbWUgKDxjc3ZEb21haW46Zk5hbWU+KSBhbmQgbm90IHRoZSBkb21haW4gaWQg KDxjc3ZEb21haW46ZlJvaWQ+KS4gIEFkZGl0aW9uYWxseSwgdGhlIGxhdW5jaCBzdW5yaXNlIGFu ZCBjbGFpbXMgYXR0cmlidXRlcyBhcmUgbm90IHN1cHBvcnRlZCAocGhhc2UsIFNNRCBpZGVudGlm aWVyLCBtYXJrLCBhcHBsaWNhdGlvbiBzdGF0dXMsIGNsYWltcyBub3RpY2UgaWRlbnRpZmllciwg Y2xhaW1zIHZhbGlkYXRvciBpZGVudGlmaWVyLCBjbGFpbXMgYWNjZXB0ZWQgZGF0ZSwgZXRjLiku ICBJIGNyZWF0ZWQgYSB2ZXJzaW9uIG9mIHRoZSBkcmFmdCB0aGF0IHN3aXRjaGVkIHRoZSBkb21h aW4gQ1NWIHByaW1hcnkga2V5IHRvIDxjc3ZEb21haW46ZlJvaWQ+IGFuZCBhZGRlZCB0aGUgQ1NW IGxhdW5jaCBmaWVsZHMgZm9yIHN1bnJpc2UgYW5kIGNsYWltcy4gICBJdCBpcyBjaGVja2VkIGlu IGF0IHRoZSBHaXRIdWIgcHJvamVjdCBodHRwczovL2dpdGh1Yi5jb20vamFtZXMtZi1nb3VsZC9k cmFmdC1yeWRlLiAgSSB3b3VsZCBsaWtlIHRvIGhlYXIgd2hldGhlciBzdWNoIGEgY2hhbmdlIGlz IG5lZWRlZC4gIEFueSBmZWVkYmFjayBpcyB3ZWxjb21lLg0KDQpUaGFua3MsDQoNCi0tDQoNCkpH DQoNCltjaWQ6Qzc3NjM0QzgtOTRCMy00QTg2LUI4QTMtMkVGMThGQzNFNUJCXQ0KDQpKYW1lcyBH b3VsZA0KUHJpbmNpcGFsIFNvZnR3YXJlIEVuZ2luZWVyDQpqZ291bGRAdmVyaXNpZ24uY29tDQoN CjcwMy05NDgtMzI3MSAoT2ZmaWNlKQ0KMTIwNjEgQmx1ZW1vbnQgV2F5DQpSZXN0b24sIFZBIDIw MTkwDQpWZXJpc2lnbkluYy5jb20NCuKAnFRoaXMgbWVzc2FnZSAoaW5jbHVkaW5nIGFueSBhdHRh Y2htZW50cykgaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBv ciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLCBhbmQgbWF5IGNvbnRhaW4gaW5mb3Jt YXRpb24gdGhhdCBpcyBub24tcHVibGljLCBwcm9wcmlldGFyeSwgcHJpdmlsZWdlZCwgY29uZmlk ZW50aWFsIGFuZCBleGVtcHQgZnJvbSBkaXNjbG9zdXJlIHVuZGVyIGFwcGxpY2FibGUgbGF3IG9y IG1heSBiZSBjb25zdGl0dXRlZCBhcyBhdHRvcm5leSB3b3JrIHByb2R1Y3QuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQg YW55IHVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciBjb3B5aW5nIG9mIHRoaXMg Y29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIG5vdGlmeSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRl bGV0ZSB0aGlzIG1lc3NhZ2UgaW1tZWRpYXRlbHku4oCdDQo= --_000_CF9789B85EC52jgouldverisigncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5JdCB3YXMgYnJv dWdodCB0byBteSBhdHRlbnRpb24gYSBsaXR0bGUgd2hpbGUgYmFjayB0aGF0IGEgcmVnaXN0cnkg d2FzIGhhdmluZyBkaWZmaWN1bHR5IGRlcG9zaXRpbmcgbGF1bmNoIGFwcGxpY2F0aW9ucyB1c2lu ZyB0aGUgQ1NWIG1vZGVsIG9mJm5ic3A7ZHJhZnQtYXJpYXMtbm9ndWNoaS1kbnJkLW9iamVjdHMt bWFwcGluZywgc2luY2UgdGhlIHByaW1hcnkga2V5IG9mIHRoZSBDU1YgZmlsZXMgaXMgdGhlIGRv bWFpbiBuYW1lICgmbHQ7Y3N2RG9tYWluOmZOYW1lJmd0OykNCiBhbmQgbm90IHRoZSBkb21haW4g aWQgKCZsdDtjc3ZEb21haW46ZlJvaWQmZ3Q7KS4gJm5ic3A7QWRkaXRpb25hbGx5LCB0aGUgbGF1 bmNoIHN1bnJpc2UgYW5kIGNsYWltcyBhdHRyaWJ1dGVzIGFyZSBub3Qgc3VwcG9ydGVkIChwaGFz ZSwgU01EIGlkZW50aWZpZXIsIG1hcmssIGFwcGxpY2F0aW9uIHN0YXR1cywgY2xhaW1zIG5vdGlj ZSBpZGVudGlmaWVyLCBjbGFpbXMgdmFsaWRhdG9yIGlkZW50aWZpZXIsIGNsYWltcyBhY2NlcHRl ZCBkYXRlLCBldGMuKS4gJm5ic3A7SSBjcmVhdGVkDQogYSB2ZXJzaW9uIG9mIHRoZSBkcmFmdCB0 aGF0IHN3aXRjaGVkIHRoZSBkb21haW4gQ1NWIHByaW1hcnkga2V5IHRvICZsdDtjc3ZEb21haW46 ZlJvaWQmZ3Q7IGFuZCBhZGRlZCB0aGUgQ1NWIGxhdW5jaCBmaWVsZHMgZm9yIHN1bnJpc2UgYW5k IGNsYWltcy4gJm5ic3A7IEl0IGlzIGNoZWNrZWQgaW4gYXQgdGhlIEdpdEh1YiBwcm9qZWN0Jm5i c3A7PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2phbWVzLWYtZ291bGQvZHJhZnQtcnlkZSI+ aHR0cHM6Ly9naXRodWIuY29tL2phbWVzLWYtZ291bGQvZHJhZnQtcnlkZTwvYT4uDQogJm5ic3A7 SSB3b3VsZCBsaWtlIHRvIGhlYXIgd2hldGhlciBzdWNoIGEgY2hhbmdlIGlzIG5lZWRlZC4gJm5i c3A7QW55IGZlZWRiYWNrIGlzIHdlbGNvbWUuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5UaGFua3MsPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOzwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6IENhbWJyaWE7ICI+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXpl PSIzIj4tLSZuYnNwOzxvOnA+PC9vOnA+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6IENhbWJyaWE7ICI+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIzIj4mbmJzcDs8 bzpwPjwvbzpwPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBDYW1icmlh OyAiPg0KPGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMyI+Skc8bzpwPjwvbzpwPjwvZm9udD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0 OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBDYW1icmlhOyAiPg0KPGZvbnQgZmFjZT0i Q2FsaWJyaSIgc2l6ZT0iMyI+Jm5ic3A7PG86cD48L286cD48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogQ2FtYnJpYTsgIj4NCjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9 IjMiPjxpbWcgd2lkdGg9Ijc1IiBoZWlnaHQ9IjY2IiBzcmM9ImNpZDpDNzc2MzRDOC05NEIzLTRB ODYtQjhBMy0yRUYxOEZDM0U1QkIiIHY6c2hhcGVzPSJQaWN0dXJlX3gwMDIwXzEiIHR5cGU9Imlt YWdlL3BuZyI+PG86cD48L286cD48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogQ2FtYnJpYTsgIj4NCjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjMiPiZuYnNwOzxvOnA+ PC9vOnA+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IENhbWJyaWE7ICI+ DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIzIj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigx MiwgMjksIDk5KTsgIj5KYW1lcyBHb3VsZDwvc3Bhbj48bzpwPjwvbzpwPjwvZm9udD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBDYW1icmlhOyAiPg0KPGZvbnQgZmFjZT0iQ2FsaWJy aSIgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNDEsIDQyLCA0NSk7ICI+UHJpbmNp cGFsIFNvZnR3YXJlIEVuZ2luZWVyPC9zcGFuPjxvOnA+PC9vOnA+PC9mb250PjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6IENhbWJyaWE7ICI+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBz aXplPSIzIj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAyMTkpOyAiPmpnb3VsZEB2ZXJp c2lnbi5jb208L3NwYW4+PG86cD48L286cD48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogQ2FtYnJpYTsgIj4NCjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjMiPjxzcGFu IHN0eWxlPSJjb2xvcjogcmdiKDQxLCA0MiwgNDUpOyAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBDYW1icmlhOyAiPg0KPGZv bnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNDEsIDQy LCA0NSk7ICI+NzAzLTk0OC0zMjcxIChPZmZpY2UpPC9zcGFuPjxvOnA+PC9vOnA+PC9mb250Pjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IENhbWJyaWE7ICI+DQo8Zm9udCBmYWNlPSJD YWxpYnJpIiBzaXplPSIzIj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzOSwgNDEsIDQzKTsgIj4x MjA2MSBCbHVlbW9udCBXYXk8L3NwYW4+PG86cD48L286cD48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogQ2FtYnJpYTsgIj4NCjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9 IjMiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDM5LCA0MSwgNDMpOyAiPlJlc3RvbiwgVkEgMjAx OTA8L3NwYW4+PG86cD48L286cD48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogQ2FtYnJpYTsgIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDEyLCAyOSwgOTkpOyAiPjxm b250IGZhY2U9IkNhbGlicmkiIHNpemU9IjMiPlZlcmlzaWduSW5jLmNvbTwvZm9udD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8aDU+PGZvbnQgY29sb3I9ImdyYXkiPuKAnFRoaXMgbWVzc2FnZSAoaW5j bHVkaW5nIGFueSBhdHRhY2htZW50cykgaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0 aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLCBhbmQgbWF5 IGNvbnRhaW4gaW5mb3JtYXRpb24gdGhhdCBpcyBub24tcHVibGljLCBwcm9wcmlldGFyeSwgcHJp dmlsZWdlZCwgY29uZmlkZW50aWFsIGFuZCBleGVtcHQgZnJvbSBkaXNjbG9zdXJlDQogdW5kZXIg YXBwbGljYWJsZSBsYXcgb3IgbWF5IGJlIGNvbnN0aXR1dGVkIGFzIGF0dG9ybmV5IHdvcmsgcHJv ZHVjdC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJl Ynkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9y IGNvcHlpbmcgb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMNCiBtZXNzYWdlIGluIGVycm9yLCBub3RpZnkgc2VuZGVy IGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGltbWVkaWF0ZWx5LuKAnQ0KPC9o NT4NCjwvZm9udD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CF9789B85EC52jgouldverisigncom_-- --_004_CF9789B85EC52jgouldverisigncom_ Content-Type: image/png; name="3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[14].png" Content-Description: 3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[14].png Content-Disposition: inline; filename="3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[14].png"; size=4109; creation-date="Tue, 13 May 2014 12:34:06 GMT"; modification-date="Tue, 13 May 2014 12:34:06 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_CF9789B85EC52jgouldverisigncom_-- From nobody Tue May 13 17:22:43 2014 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445C61A010E for ; Tue, 13 May 2014 17:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.196 X-Spam-Level: X-Spam-Status: No, score=-1.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0FnAtb-r8dz for ; Tue, 13 May 2014 17:22:41 -0700 (PDT) Received: from mx02.ausregistry.net.au (mx02.ausregistry.net.au [120.29.255.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0B31A010B for ; Tue, 13 May 2014 17:22:40 -0700 (PDT) Received: from offex01.ausregistrygroup.local (HELO ausregistry.com.au) ([10.30.220.61]) by iron02.off08.stkildard.vic.ausregistry.com.au with ESMTP; 14 May 2014 10:22:17 +1000 Received: from MELEX01.ausregistrygroup.local ([10.11.220.61]) by OFFEX01.ausregistrygroup.local ([169.254.2.50]) with mapi id 14.03.0174.001; Wed, 14 May 2014 10:22:22 +1000 From: James Mitchell To: "Gould, James" , "ire@ietf.org" Thread-Topic: [ire] Support for Launch Applications and Claims in draft-arias-noguchi-dnrd-objects-mapping Thread-Index: AQHPbwqS6xE6Joy1ckGIpaNZrzK0eA== Date: Wed, 14 May 2014 00:22:21 +0000 Message-ID: Accept-Language: en-NZ, en-AU, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.30.16.78] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/mixed; boundary="_004_CF98EB1B514DAjamesmitchellausregistrycomau_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ire/wNbqK4fJ__TN7C1-62reoZwjqKg Subject: Re: [ire] Support for Launch Applications and Claims in draft-arias-noguchi-dnrd-objects-mapping X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 00:22:43 -0000 --_004_CF98EB1B514DAjamesmitchellausregistrycomau_ Content-Type: multipart/alternative; boundary="_000_CF98EB1B514DAjamesmitchellausregistrycomau_" --_000_CF98EB1B514DAjamesmitchellausregistrycomau_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable SMD and Claims information should not be included in the deposit as in most= cases this is akin to the escrow of partial historical information not req= uired to rebuild a working registry. However those registry operators that = offer services that depend on, or require this information for the operatio= n of the registry, should be escrowing this data already as prescribed in t= he Registry Agreement, Specification 2, Section 3.2, copied below for every= ones reference. 3.2. Extensions. If a Registry Operator offers additional Regis= try Services that require submission of additional data, not included above= , additional =93extension schemas=94 shall be defined in a case by case bas= is to represent that data. These =93extension schemas=94 will be specified= as described in Part A, Section 9, reference 2 of this Specification. Dat= a related to the =93extensions schemas=94 will be included in the deposit f= ile described in Part A, Section 3.1 of this Specification. ICANN and the = respective Registry Operator shall work together to agree on such new objec= ts=92 data escrow specifications. I believe this is an ideal candidate to continue as a separate extension in= dependent of the already unreadable escrow specification. Further, I don=92= t foresee any need to restore a failed registry into pending launch phase a= nd would rather not see it in the specification. Again, I would consider it= as an extension and treated as above. Regards, James Mitchell Product Manager / ARI Registry Services From: , James > Date: Tuesday, 13 May 2014 10:34 pm To: "ire@ietf.org" > Subject: [ire] Support for Launch Applications and Claims in draft-arias-no= guchi-dnrd-objects-mapping It was brought to my attention a little while back that a registry was havi= ng difficulty depositing launch applications using the CSV model of draft-a= rias-noguchi-dnrd-objects-mapping, since the primary key of the CSV files i= s the domain name () and not the domain id (). Additionally, the launch sunrise and claims attributes are not suppo= rted (phase, SMD identifier, mark, application status, claims notice identi= fier, claims validator identifier, claims accepted date, etc.). I created = a version of the draft that switched the domain CSV primary key to and added the CSV launch fields for sunrise and claims. It is c= hecked in at the GitHub project https://github.com/james-f-gould/draft-ryde= . I would like to hear whether such a change is needed. Any feedback is w= elcome. Thanks, -- JG [cid:C77634C8-94B3-4A86-B8A3-2EF18FC3E5BB] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com =93This message (including any attachments) is intended only for the use of= the individual or entity to which it is addressed, and may contain informa= tion that is non-public, proprietary, privileged, confidential and exempt f= rom disclosure under applicable law or may be constituted as attorney work = product. If you are not the intended recipient, you are hereby notified tha= t any use, dissemination, distribution, or copying of this communication is= strictly prohibited. If you have received this message in error, notify se= nder immediately and delete this message immediately.=94 --_000_CF98EB1B514DAjamesmitchellausregistrycomau_ Content-Type: text/html; charset="Windows-1252" Content-ID: <396665C2666DD34CB56DE5EA32BD6E85@ausregistry.com.au> Content-Transfer-Encoding: quoted-printable
SMD and Claims information should not be included in the deposit as in most= cases this is akin to the escrow of partial historical information not req= uired to rebuild a working registry. However those registry operators that = offer services that depend on, or require this information for the operation of the registry, should be escr= owing this data already as prescribed in the Registry Agreement, Specificat= ion 2, Section 3.2, copied below for everyones reference. 

3.2.         =    Extensions.  If a Registry Operator offers additional Reg= istry Services that require submission of additional data, not included abo= ve, additional =93extension schemas=94 shall be defined in a case by case basis to represent that data.  These =93extension schemas=94 will be = specified as described in Part A, Section 9, reference 2 of this Specificat= ion.  Data related to the =93extensions schemas=94 will be included in= the deposit file described in Part A, Section 3.1 of this Specification.  ICANN and the respective Registry Operator sh= all work together to agree on such new objects=92 data escrow specification= s.

I believe this is an ideal candidate to continue as a separate extension in= dependent of the already unreadable escrow specification. Further, I don=92= t foresee any need to restore a failed registry into pending launch phase a= nd would rather not see it in the specification. Again, I would consider it as an extension and treated as a= bove.

Regards,
James Mitchell
Product Manager / ARI Registry Services

From: <Gould>, James <JGould@verisign.com>
Date: Tuesday, 13 May 2014 10:34 pm=
To: "ire@ietf.org" <ire@ietf.= org>
Subject: [ire] Support for Launch A= pplications and Claims in draft-arias-noguchi-dnrd-objects-mapping

It was brought to my attention a little while back that a registry was= having difficulty depositing launch applications using the CSV model of&nb= sp;draft-arias-noguchi-dnrd-objects-mapping, since the primary key of the C= SV files is the domain name (<csvDomain:fName>) and not the domain id (<csvDomain:fRoid>).  Additionally, the l= aunch sunrise and claims attributes are not supported (phase, SMD identifie= r, mark, application status, claims notice identifier, claims validator ide= ntifier, claims accepted date, etc.).  I created a version of the draft that switched the domain CSV primary key to <csv= Domain:fRoid> and added the CSV launch fields for sunrise and claims. &n= bsp; It is checked in at the GitHub project https://github.com/james-f-gould/draft-ryde.  I would like to hear whether such a change is needed.  Any feed= back is welcome.

Thanks,
  

-- 

 

JG

 

 

= James Gould

= Principal Software Engineer

<= a href=3D"mailto:jgould@verisign.com">jgould@verisign.com

=  

= 703-948-3271 (Office)

= 12061 Bluemont Way

= Reston, VA 20190

= VerisignInc.com

=93This message (including any attachments) is int= ended only for the use of the individual or entity to which it is addressed= , and may contain information that is non-public, proprietary, privileged, = confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If yo= u are not the intended recipient, you are hereby notified that any use, dis= semination, distribution, or copying of this communication is strictly proh= ibited. If you have received this message in error, notify sender immediately and delete this message immedi= ately.=94
--_000_CF98EB1B514DAjamesmitchellausregistrycomau_-- --_004_CF98EB1B514DAjamesmitchellausregistrycomau_ Content-Type: image/png; name="3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[14].png" Content-Description: 3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[14].png Content-Disposition: attachment; filename="3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[14].png"; size=4109; creation-date="Wed, 14 May 2014 00:22:21 GMT"; modification-date="Wed, 14 May 2014 00:22:21 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_CF98EB1B514DAjamesmitchellausregistrycomau_-- From nobody Wed May 14 05:25:44 2014 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958AE1A0071 for ; Wed, 14 May 2014 05:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5J_qpVA_N0T for ; Wed, 14 May 2014 05:25:38 -0700 (PDT) Received: from exprod6og124.obsmtp.com (exprod6og124.obsmtp.com [64.18.1.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE1B1A005F for ; Wed, 14 May 2014 05:25:36 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob124.postini.com ([64.18.5.12]) with SMTP ID DSNKU3NguCJ2+B0lVRChJgKA33KtKutOxi7Y@postini.com; Wed, 14 May 2014 05:25:31 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s4ECPPZU005878 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 May 2014 08:25:25 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 14 May 2014 08:25:25 -0400 From: "Gould, James" To: "james.mitchell@ausregistry.com.au" , "ire@ietf.org" Thread-Topic: [ire] Support for Launch Applications and Claims in draft-arias-noguchi-dnrd-objects-mapping Thread-Index: AQHPbwqS6xE6Joy1ckGIpaNZrzK0eJtAAVqA Date: Wed, 14 May 2014 12:25:24 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.173.152.4] Content-Type: multipart/mixed; boundary="_006_CF98D7F85EDD7jgouldverisigncom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ire/QzuJAiLhA2k6H5r3SUGx5jwTQkM Subject: Re: [ire] Support for Launch Applications and Claims in draft-arias-noguchi-dnrd-objects-mapping X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 12:25:42 -0000 --_006_CF98D7F85EDD7jgouldverisigncom_ Content-Type: multipart/related; boundary="_005_CF98D7F85EDD7jgouldverisigncom_"; type="multipart/alternative" --_005_CF98D7F85EDD7jgouldverisigncom_ Content-Type: multipart/alternative; boundary="_000_CF98D7F85EDD7jgouldverisigncom_" --_000_CF98D7F85EDD7jgouldverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable James, Thanks for your feedback. I do agree that the pending launch information i= s not necessary to rebuild a typical registry. Are there any registries ou= t there that have a need for escrowing the additional launch information (a= pplications and additional sunrise and claims attributes) and if so whether= it should be integrated into draft-arias-noguchi-dnrd-objects-mapping or c= reated as an extension outside of draft-arias-noguchi-dnrd-objects-mapping? Thanks, -- JG [cid:BD35E913-0B4F-43FB-B30E-B67D18E0CB8E] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: James Mitchell > Date: Tuesday, May 13, 2014 at 8:22 PM To: James Gould >, "ire@iet= f.org" > Subject: Re: [ire] Support for Launch Applications and Claims in draft-aria= s-noguchi-dnrd-objects-mapping SMD and Claims information should not be included in the deposit as in most= cases this is akin to the escrow of partial historical information not req= uired to rebuild a working registry. However those registry operators that = offer services that depend on, or require this information for the operatio= n of the registry, should be escrowing this data already as prescribed in t= he Registry Agreement, Specification 2, Section 3.2, copied below for every= ones reference. 3.2. Extensions. If a Registry Operator offers additional Regis= try Services that require submission of additional data, not included above= , additional =93extension schemas=94 shall be defined in a case by case bas= is to represent that data. These =93extension schemas=94 will be specified= as described in Part A, Section 9, reference 2 of this Specification. Dat= a related to the =93extensions schemas=94 will be included in the deposit f= ile described in Part A, Section 3.1 of this Specification. ICANN and the = respective Registry Operator shall work together to agree on such new objec= ts=92 data escrow specifications. I believe this is an ideal candidate to continue as a separate extension in= dependent of the already unreadable escrow specification. Further, I don=92= t foresee any need to restore a failed registry into pending launch phase a= nd would rather not see it in the specification. Again, I would consider it= as an extension and treated as above. Regards, James Mitchell Product Manager / ARI Registry Services From: , James > Date: Tuesday, 13 May 2014 10:34 pm To: "ire@ietf.org" > Subject: [ire] Support for Launch Applications and Claims in draft-arias-no= guchi-dnrd-objects-mapping It was brought to my attention a little while back that a registry was havi= ng difficulty depositing launch applications using the CSV model of draft-a= rias-noguchi-dnrd-objects-mapping, since the primary key of the CSV files i= s the domain name () and not the domain id (). Additionally, the launch sunrise and claims attributes are not suppo= rted (phase, SMD identifier, mark, application status, claims notice identi= fier, claims validator identifier, claims accepted date, etc.). I created = a version of the draft that switched the domain CSV primary key to and added the CSV launch fields for sunrise and claims. It is c= hecked in at the GitHub project https://github.com/james-f-gould/draft-ryde= . I would like to hear whether such a change is needed. Any feedback is w= elcome. Thanks, -- JG [cid:C77634C8-94B3-4A86-B8A3-2EF18FC3E5BB] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com =93This message (including any attachments) is intended only for the use of= the individual or entity to which it is addressed, and may contain informa= tion that is non-public, proprietary, privileged, confidential and exempt f= rom disclosure under applicable law or may be constituted as attorney work = product. If you are not the intended recipient, you are hereby notified tha= t any use, dissemination, distribution, or copying of this communication is= strictly prohibited. If you have received this message in error, notify se= nder immediately and delete this message immediately.=94 --_000_CF98D7F85EDD7jgouldverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
James,

Thanks for your feedback.  I do agree that the pending launch inf= ormation is not necessary to rebuild a typical registry.  Are there an= y registries out there that have a need for escrowing the additional launch= information (applications and additional sunrise and claims attributes) and if so whether it should be integrated i= nto draft-arias-noguchi-dnrd-objects-mapping or created as an extensio= n outside of draft-arias-noguchi-dnrd-objects-mapping?  

Thanks,

-- 

 

JG

 

 

= James Gould

= Principal Software Engineer

j= gould@verisign.com

=  

= 703-948-3271 (Office)

= 12061 Bluemont Way

= Reston, VA 20190

= VerisignInc.com


From: James Mitchell <james.mitchell@ausregistry.com.a= u>
Date: Tuesday, May 13, 2014 at 8:22= PM
To: James Gould <jgould@verisign.com>, "ire@ietf.org" <= ire@ietf.org>
Subject: Re: [ire] Support for Laun= ch Applications and Claims in draft-arias-noguchi-dnrd-objects-mapping

SMD and Claims information should not be included in the deposit as in most= cases this is akin to the escrow of partial historical information not req= uired to rebuild a working registry. However those registry operators that = offer services that depend on, or require this information for the operation of the registry, should be escr= owing this data already as prescribed in the Registry Agreement, Specificat= ion 2, Section 3.2, copied below for everyones reference. 

3.2.         =    Extensions.  If a Registry Operator offers additional Reg= istry Services that require submission of additional data, not included abo= ve, additional =93extension schemas=94 shall be defined in a case by case basis to represent that data.  These =93extension schemas=94 will be = specified as described in Part A, Section 9, reference 2 of this Specificat= ion.  Data related to the =93extensions schemas=94 will be included in= the deposit file described in Part A, Section 3.1 of this Specification.  ICANN and the respective Registry Operator sh= all work together to agree on such new objects=92 data escrow specification= s.

I believe this is an ideal candidate to continue as a separate extension in= dependent of the already unreadable escrow specification. Further, I don=92= t foresee any need to restore a failed registry into pending launch phase a= nd would rather not see it in the specification. Again, I would consider it as an extension and treated as a= bove.

Regards,
James Mitchell
Product Manager / ARI Registry Services

From: <Gould>, James <JGould@verisign.com>
Date: Tuesday, 13 May 2014 10:34 pm=
To: "ire@ietf.org" <ire@ietf.= org>
Subject: [ire] Support for Launch A= pplications and Claims in draft-arias-noguchi-dnrd-objects-mapping

It was brought to my attention a little while back that a registry was= having difficulty depositing launch applications using the CSV model of&nb= sp;draft-arias-noguchi-dnrd-objects-mapping, since the primary key of the C= SV files is the domain name (<csvDomain:fName>) and not the domain id (<csvDomain:fRoid>).  Additionally, the l= aunch sunrise and claims attributes are not supported (phase, SMD identifie= r, mark, application status, claims notice identifier, claims validator ide= ntifier, claims accepted date, etc.).  I created a version of the draft that switched the domain CSV primary key to <csv= Domain:fRoid> and added the CSV launch fields for sunrise and claims. &n= bsp; It is checked in at the GitHub project https://github.com/james-f-gould/draft-ryde.  I would like to hear whether such a change is needed.  Any feed= back is welcome.

Thanks,
  

-- 

 

JG

 

 

= James Gould

= Principal Software Engineer

<= a href=3D"mailto:jgould@verisign.com">jgould@verisign.com

=  

= 703-948-3271 (Office)

= 12061 Bluemont Way

= Reston, VA 20190

= VerisignInc.com

=93This message (including any attachments) is int= ended only for the use of the individual or entity to which it is addressed= , and may contain information that is non-public, proprietary, privileged, = confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If yo= u are not the intended recipient, you are hereby notified that any use, dis= semination, distribution, or copying of this communication is strictly proh= ibited. If you have received this message in error, notify sender immediately and delete this message immedi= ately.=94
--_000_CF98D7F85EDD7jgouldverisigncom_-- --_005_CF98D7F85EDD7jgouldverisigncom_ Content-Type: image/png; name="3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[22].png" Content-Description: 3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[22].png Content-Disposition: inline; filename="3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[22].png"; size=4109; creation-date="Wed, 14 May 2014 12:25:24 GMT"; modification-date="Wed, 14 May 2014 12:25:24 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_005_CF98D7F85EDD7jgouldverisigncom_-- --_006_CF98D7F85EDD7jgouldverisigncom_ Content-Type: image/png; name="3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[14].png" Content-Description: 3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[14].png Content-Disposition: attachment; filename="3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[14].png"; size=4109; creation-date="Wed, 14 May 2014 12:25:24 GMT"; modification-date="Wed, 14 May 2014 12:25:24 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_006_CF98D7F85EDD7jgouldverisigncom_--