Subject: Re: [ire] New version (4) of the spec and new draft on DNRD (1)

From: Francisco Obispo <[email-masked]>
Date: Wed, 5 Dec 2012 15:35:55 -0800

Hi James,

Now that I've spent a few hours on our implementation, let me add my two cents as well:

On Nov 14, 2012, at 3:06 PM, "Gould, James" <[email-masked]> wrote:

> Gustavo,
> 
> Below is my feedback for draft-arias-noguchi-dnrd-objects-mapping-01:
> 
> 	• High level
> 		• There was support for an <extension> element for each of the objects (domain, host, and contact) in draft-arias-noguchi-registry-data-escrow-02 that never made it into draft-arias-noguchi-dnrd-objects-mapping.  What is the mechanism to include attribute extensions for the objects?
> 	• Domain Object
> 		• Based on feedback to the NNDN Object I suggest adding the following domain object elements:
> 			• <uName> - An OPTIONAL UTF-8 encoded fully qualified name of the IDN domain name object.
> 			• <idn> - An OPTIONAL boolean flag indicating if the domain name object is an IDN domain name object.
> 			• <language> - An OPTIONAL language tag value for an IDN domain name object. The language tag value MUST be one of the <language> elements contained in an <idnTableRef> element
> 			• <variant> - An OPTIONAL boolean flag indicating if the domain name object is an IDN variant domain name object. If the <variant> value is "true" the <originalName> SHOULD be set with the original IDN domain name object.
> 			• <originalName> - An OPTIONAL fully qualified name of the original IDN domain name object related to the variant domain name object. This value SHOULD be set if <variant> is "true".
> 			• <reserved> - An OPTIONAL boolean flag indicating if the domain name object is a reserved domain name object. A reserved domain name object is not registered by a client but by the server to ensure that it can't be registered by a client.

This seems reasonable and it would remove the need to have the NNDN Object.

> 		• <deDate> is not typically a true data element in the SRS since it is calculated by the RGP policies.  There can be other statuses that have additional date policies like other pending statuses (pendingCreate, pendingUpdate, pendingRestore).  It would be better to include a date (created date) that a status was set that matches what is typically included in the data model along with a pending status policy set of elements.  This way it makes it straight forward to create the deposits and consume the deposits.

Agreed, we should remove it!

> 		• <variantGenerator> might not be needed.  If variants are blocked or available only to the registrant of the original IDN then that could be captured in a registry policy descriptor instead of on a per domain basis.  Inclusion of the canonical variant won't be of much use for an EBERO provider, since the EBERO provider would generate the canonical variant using their canonical variant generation function. 

+1

>  
> 	• Host Object
> 		• Should an optional <uName> be supported similar to a <uName> element for the domain object?

Yes

> 		• Should a <parentDomain> element be added?
> 			• An OPTIONAL parent domain name for the subordinate host object.

No, this can be calculated by looking at the labels.

> 		• Could add an <idn> element similar to what I propose for the domain object
> 			• An OPTIONAL boolean flag indicating if the host object is an IDN host object.

We could trigger that with the presence of the uName field above. 

> 	• Contact Object
> 		• The <roid> element is missing from the list of elements
> 		• Registrar contacts çan be different from object contacts since they are typically not provisioned via EPP and they could have types directly assigned to them (admin, tech, billing, legal, icann, abuse, etc.). It would be good to be able to identify which contacts are registrar contacts versus object contacts and support a set of optional registrar contact elements. The registrar contact could be routed to a different data source (e.g. account / registrar database) instead of being included in the registry database directly.  The draft-gould-thippeswamy-dnrd-csv-mapping-01 draft defines some of the registrar contact specific attributes for reference.

I agree with this approach, we in fact have two separate databases, so it makes a lot of sense to me.

> 	• Registrar Object
> 		• It would be good to support a <status> element that could support a single status value like below with an optional name attribute to define the sub-status or the custom status name:
> 			• ok - A normal status value for a registrar object.
> 			• Hold - A restricted status value for a registrar object.
> 			• Terminated - A status for a registrar object that has no remaining access or privileges.
> 			• Custom - A custom status that is defined using the "name" attribute.

Works for me.

> 		• Recommend not reusing the <postalInfo> element of the contact object for the registrar.  I recommend including the  following registrar specific elements:
> 			• <name> - One or two <rdeRegistrar:name> elements that contain the name of the registrar. Two elements are provided so that name information can be provided in both internationlized and localized forms
> 			• <addr> from the contact <postalInfo> element.

+1

> 		• I don't believe there is any need for an <authInfo> element for the registrar object.

Excellent point, in fact, we don't currently store the registrar's password in the clear (it is handled by the database), and since there is already the need to get new certificate requests signed for TLS validation, that is something that can be configured at that time, no need to risk storing passwords in the clear because I'm envisioning that there will be humans involved in getting the registrars on board.

> 		• Add <crID> <upID> elements similar to the other objects.
> 	• NNDN Object 
> 		• Wouldn't it be better to merge the domain object with the NNDN object, since the NNDN object attributes are just additional attributes for domains (e.g. IDN domain)

Yes, lets get rid of it.

Finally, I've been trying to setup the XML Schema Validation, but have found the Schemas to be poorly defined, specially when using complexTypes from EPP objects. Unless I'm missing something, we'll have to re-define the complexTypes in the rde* Schemas, to avoid using the EPP namespaces in the rde* instances.

t/tmp/test_01.xml:1: element name: Schemas validity error : Element '{urn:ietf:params:xml:ns:rdeContact-1.0}name': This element is not expected. Expected is ( {urn:ietf:params:xml:ns:contact-1.0}name ).

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

---

From: "Gould, James" <[email-masked]>
Date: Thu, 13 Dec 2012 16:16:38 +0000

Gustavo,

I noticed the following additional items with draft-arias-noguchi-dnrd-objects-mapping-01:

  1.  The description of the <crID> and <upID> should match what is in the EPP RFC's.  Specifically, change "identifier of the registrar" to "identifier of the client".  In our registries we have account users (verisign as well as registrar) that are reflected in the <crID> and <upID> fields via the user's user name (e.g. jgould).  This is important to track exactly who took the action, since actions can be taken outside of the EPP channel (Registrar Tool, CSR Tool, batch) that should properly be reflected in the <crID> and <upID> elements.  Now the next logical question is whether there needs to be a deposit for users to link the "client identifiers" to.  I would imagine that an EBERO provider would import the <crID> and <upID> fields as strings and replace them (most likely using different fields) with real user identifiers based on future updates to the objects.
  2.  The question is whether the authInfo should be escrowed at all since these reflect secret passwords.  Our system stores them encrypted and I don't believe it is a good security practice to escrow them in a decrypted form or even provide a tool that can decrypt them.  I believe that the EBERO provider recovering a registry from the data escrow deposit can generate new random authorization info values and make them available in bulk to the registrars or on-demand by the registrars submitting an EPP info command for the objects.  What are your thoughts with this?

--

JG

James Gould
Principal Software Engineer
[email-masked]

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

From: <Gould>, James Gould <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 14, 2012 6:06 PM
To: Gustavo Lozano <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ire] New version (4) of the spec and new draft on DNRD (1)

Gustavo,

  *   High level
     *   There was support for an <extension> element for each of the objects (domain, host, and contact) in draft-arias-noguchi-registry-data-escrow-02 that never made it into draft-arias-noguchi-dnrd-objects-mapping.  What is the mechanism to include attribute extensions for the objects?
  *   Domain Object
     *   Based on feedback to the NNDN Object I suggest adding the following domain object elements:
        *   <uName> - An OPTIONAL UTF-8 encoded fully qualified name of the IDN domain name object.
        *   <idn> - An OPTIONAL boolean flag indicating if the domain name object is an IDN domain name object.
        *   <language> - An OPTIONAL language tag value for an IDN domain name object. The language tag value MUST be one of the <language> elements contained in an <idnTableRef> element
        *   <variant> - An OPTIONAL boolean flag indicating if the domain name object is an IDN variant domain name object. If the <variant> value is "true" the <originalName> SHOULD be set with the original IDN domain name object.
        *   <originalName> - An OPTIONAL fully qualified name of the original IDN domain name object related to the variant domain name object. This value SHOULD be set if <variant> is "true".
        *   <reserved> - An OPTIONAL boolean flag indicating if the domain name object is a reserved domain name object. A reserved domain name object is not registered by a client but by the server to ensure that it can't be registered by a client.
     *   <deDate> is not typically a true data element in the SRS since it is calculated by the RGP policies.  There can be other statuses that have additional date policies like other pending statuses (pendingCreate, pendingUpdate, pendingRestore).  It would be better to include a date (created date) that a status was set that matches what is typically included in the data model along with a pending status policy set of elements.  This way it makes it straight forward to create the deposits and consume the deposits.
     *   <variantGenerator> might not be needed.  If variants are blocked or available only to the registrant of the original IDN then that could be captured in a registry policy descriptor instead of on a per domain basis.  Inclusion of the canonical variant won't be of much use for an EBERO provider, since the EBERO provider would generate the canonical variant using their canonical variant generation function.
  *   Host Object
     *   Should an optional <uName> be supported similar to a <uName> element for the domain object?
     *   Should a <parentDomain> element be added?
        *   An OPTIONAL parent domain name for the subordinate host object.
     *   Could add an <idn> element similar to what I propose for the domain object
        *   An OPTIONAL boolean flag indicating if the host object is an IDN host object.
  *   Contact Object
     *   The <roid> element is missing from the list of elements
     *   Registrar contacts çan be different from object contacts since they are typically not provisioned via EPP and they could have types directly assigned to them (admin, tech, billing, legal, icann, abuse, etc.). It would be good to be able to identify which contacts are registrar contacts versus object contacts and support a set of optional registrar contact elements. The registrar contact could be routed to a different data source (e.g. account / registrar database) instead of being included in the registry database directly.  The draft-gould-thippeswamy-dnrd-csv-mapping-01 draft defines some of the registrar contact specific attributes for reference.
  *   Registrar Object
     *   It would be good to support a <status> element that could support a single status value like below with an optional name attribute to define the sub-status or the custom status name:
        *   ok - A normal status value for a registrar object.
        *   Hold - A restricted status value for a registrar object.
        *   Terminated - A status for a registrar object that has no remaining access or privileges.
        *   Custom - A custom status that is defined using the "name" attribute.
     *   Recommend not reusing the <postalInfo> element of the contact object for the registrar.  I recommend including the following registrar specific elements:
        *   <name> - One or two <rdeRegistrar:name> elements that contain the name of the registrar. Two elements are provided so that name information can be provided in both internationlized and localized forms
        *   <addr> from the contact <postalInfo> element.
     *   I don't believe there is any need for an <authInfo> element for the registrar object.
     *   Add <crID> <upID> elements similar to the other objects.
  *   NNDN Object
     *   Wouldn't it be better to merge the domain object with the NNDN object, since the NNDN object attributes are just additional attributes for domains (e.g. IDN domain)
     *   The <uName> element could be an optional domain object element
     *   The domain object could include an <idn> element that indicates whether the domain name is an IDN domain name.
     *   The <nameState> element could be reflected with the following optional domain object boolean elements:
        *   <reserved> element that matches the "blocked" tag
        *   <withheld> element that matches the "withheld" tag
        *   <variant> element that matches the "allocated" tag.  A domain object marked as a <variant> SHOULD include a <originalName> domain object element that includes the name of the original IDN (OIDN).
     *   <crDate> would already be covered by the domain object <crDate>
     *   <originElement> could be handled with an OPTIONAL domain object <originalName> element that references the domain name of the original IDN (OIDN) for a registered variant.  Replicating the registrant I don't believe would serve much of a purpose since the business logic could apply registrant equivalence or precedence rules between related IDN domains (OIDN and VIDN's).

--

JG

James Gould
Principal Software Engineer
[email-masked]<mailto:[email-masked]>

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 10/24/12 9:13 PM, "Gustavo Lozano" <[email-masked]<mailto:[email-masked]>> wrote:

All,

New versions of both data escrow drafts have been published:
http://tools.ietf.org/html/draft-arias-noguchi-dnrd-objects-mapping-01
http://tools.ietf.org/html/draft-arias-noguchi-registry-data-escrow-04

* The main update is regarding IDN variant handling. ICANN have been
working on the IDN variants project for some time and knowledge gathered
from this project has been incorporated into
draft-arias-noguchi-dnrd-objects-mapping-01.
* Some elements were removed because they were redundant and could be
derived from other elements.
* Several elements are now OPTIONAL to accommodate different domain name
registry business models.

We would like to get feedback regarding these new versions of the drafts,
especially regarding the proposed IDN variants handling approach.

Expect a new version of the drafts shortly in which we propose the
extension mechanism.

Thank you.

Regards,
Gustavo

_______________________________________________
ire mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ire

---

From: Francisco Obispo <[email-masked]>
Date: Thu, 13 Dec 2012 09:25:41 -0800

Hi James,

On Dec 13, 2012, at 8:16 AM, "Gould, James" <[email-masked]> wrote:

> 	• The description of the <crID> and <upID> should match what is in the EPP RFC's.  Specifically, change "identifier of the registrar" to "identifier of the client".  In our registries we have account users (verisign as well as registrar) that are reflected in the <crID> and <upID> fields via the user's user name (e.g. jgould).  This is important to track exactly who took the action, since actions can be taken outside of the EPP channel (Registrar Tool, CSR Tool, batch) that should properly be reflected in the <crID> and <upID> elements.  Now the next logical question is whether there needs to be a deposit for users to link the "client identifiers" to.  I would imagine that an EBERO provider would import the <crID> and <upID> fields as strings and replace them (most likely using different fields) with real user identifiers based on future updates to the objects.

I don't know about that, from the EPP perspective a *ID is a registrar not a system user, so interchanging the two doesn't seem like a good idea to me.

You could use a separate field to track those changes, without affecting the EPP semantics.

> 	• The question is whether the authInfo should be escrowed at all since these reflect secret passwords.  Our system stores them encrypted and I don't believe it is a good security practice to escrow them in a decrypted form or even provide a tool that can decrypt them.  I believe that the EBERO provider recovering a registry from the data escrow deposit can generate new random authorization info values and make them available in bulk to the registrars or on-demand by the registrars submitting an EPP info command for the objects.  What are your thoughts with this?  
> -- 

I agree with this, specially since the passwords are not the only component used to authenticate users, for example, we use IP addresses and TLS certificates as well, (we match the information in the certificate with the information associated with the clID)

In any case recovering a registry will require some time to setup these relationships, so I don't think there's a need to automate every single step.

Francisco Obispo

---

From: "Gould, James" <[email-masked]>
Date: Thu, 13 Dec 2012 17:42:37 +0000

Francisco,

My feedback is below.

-- 

JG

James Gould
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 12/13/12 12:25 PM, "Francisco Obispo" <[email-masked]> wrote:

>> I noticed the following additional items with
>>draft-arias-noguchi-dnrd-objects-mapping-01:
>> 
>> 	€ The description of the <crID> and <upID> should match what is in the
>>EPP RFC's.  Specifically, change "identifier of the registrar" to
>>"identifier of the client".  In our registries we have account users
>>(verisign as well as registrar) that are reflected in the <crID> and
>><upID> fields via the user's user name (e.g. jgould).  This is important
>>to track exactly who took the action, since actions can be taken outside
>>of the EPP channel (Registrar Tool, CSR Tool, batch) that should
>>properly be reflected in the <crID> and <upID> elements.  Now the next
>>logical question is whether there needs to be a deposit for users to
>>link the "client identifiers" to.  I would imagine that an EBERO
>>provider would import the <crID> and <upID> fields as strings and
>>replace them (most likely using different fields) with real user
>>identifiers based on future updates to the objects.
>
>I don't know about that, from the EPP perspective a *ID is a registrar
>not a system user, so interchanging the two doesn't seem like a good idea
>to me.
>

Your interpretation is different from mine of the EPP specifications.  The
term client is generic, where the reference to the "sponsoring client" in
the description of <clID> refers to the registrar.  The reference to
simply "client" in the description of crID and upID can and should refer
to any client including the actual user. It makes no sense to only return
the sponsoring client information for the crID and upID fields, since they
would pretty much almost always match the same value of clID.  It's best
to reference the actual user (Registrar User, Registry User, or whoever)
actually created or updated the object via any of the supported channels
(EPP, Registrar Web Tool, CSR Web Tool, Batch, etc.).  I believe you need
to change the description of the crID and upID fields of the data escrow
to match that of the EPP specifications.  We can continue to debate our
interpretation of the EPP specification as it relates to the crID and upID
elements.  

>
>
>> 	€ The question is whether the authInfo should be escrowed at all since
>>these reflect secret passwords.  Our system stores them encrypted and I
>>don't believe it is a good security practice to escrow them in a
>>decrypted form or even provide a tool that can decrypt them.  I believe
>>that the EBERO provider recovering a registry from the data escrow
>>deposit can generate new random authorization info values and make them
>>available in bulk to the registrars or on-demand by the registrars
>>submitting an EPP info command for the objects.  What are your thoughts
>>with this?  
>> -- 
>
>I agree with this, specially since the passwords are not the only
>component used to authenticate users, for example, we use IP addresses
>and TLS certificates as well, (we match the information in the
>certificate with the information associated with the clID)
>
>In any case recovering a registry will require some time to setup these
>relationships, so I don't think there's a need to automate every single
>step.
>
>> 
>
>Francisco Obispo

---

From: Francisco Obispo <[email-masked]>
Date: Thu, 13 Dec 2012 10:31:39 -0800

On Dec 13, 2012, at 9:42 AM, "Gould, James" <[email-masked]> wrote:

> Your interpretation is different from mine of the EPP specifications.

I find myself in this situation more ofter than I would like, but it is my job to do fine grain review, and you guys have a better view because Verisign played an important role in the authorship of the docs, which is why I come to these lists to try to get clarification to those grey areas.

>  The
> to any client including the actual user.

Yes, but my interpretation is that those fields track 'registrars' not internal users.

> It makes no sense to only return
> would pretty much almost always match the same value of clID.

Not necessarily, 

1) REGISTRAR_A  creates a domain name (crID and clID = REGISTRAR_A)
2) Domain name is transferred to REGISTRAR_B (clID = REGISTRAR_B crID = REGISTRAR_A)
3) Domain name is updated (upID=REGISTRAR_B)
4) Domain name is transferred to REGISTRAR_C (clID=REGISTRAR_C)

Final state:

clID=REGISTRAR_C
crID=REGISTRAR_A
upID=REGISTRAR_B

>  It's best

My design choice would be to keep the changes done by the registry somewhere else and not on these fields since in my opinion, they relate to authorized clients (a registry/system user might belong to a client), so in your example, it is important that 'verisign' did it and not jgould, jgould would be referenced in an audit table as a person acting on behalf of verisign performing a specific transaction in the logs.

Regards,

Francisco Obispo

---

From: Christopher Browne <[email-masked]>
Date: Thu, 13 Dec 2012 14:04:31 -0500

On Thu, Dec 13, 2012 at 11:16 AM, Gould, James <[email-masked]> wrote:
> The description of the <crID> and <upID> should match what is in the EPP
> RFC's.  Specifically, change "identifier of the registrar" to "identifier of
> the client".  In our registries we have account users (verisign as well as
> registrar) that are reflected in the <crID> and <upID> fields via the user's
> user name (e.g. jgould).  This is important to track exactly who took the
> action, since actions can be taken outside of the EPP channel (Registrar
> Tool, CSR Tool, batch) that should properly be reflected in the <crID> and
> <upID> elements.  Now the next logical question is whether there needs to be
> a deposit for users to link the "client identifiers" to.  I would imagine
> that an EBERO provider would import the <crID> and <upID> fields as strings
> and replace them (most likely using different fields) with real user
> The question is whether the authInfo should be escrowed at all since these
> reflect secret passwords.  Our system stores them encrypted and I don't
> believe it is a good security practice to escrow them in a decrypted form or
> even provide a tool that can decrypt them.  I believe that the EBERO
> provider recovering a registry from the data escrow deposit can generate new
> random authorization info values and make them available in bulk to the
> registrars or on-demand by the registrars submitting an EPP info command for
> the objects.  What are your thoughts with this?

I largely concur...  Yes, indeed, there will be some users that are
not specifically
registrars, so <crID> and <upID> are not strictly "registrars";
sometimes they will
indicate registry operator agents that are not registrars.

As for authinfo values, I'm a bit torn.

On the one hand, there is a significant problem in changing authinfo values on
the registrants, particularly when the registry operator may have no direct
channel for communicating updates to the registrants.  (This is most pointedly
the case for "thin" registries where no contact information is captured in the
registry!)

However, as soon as we are in a situation of switching registry operators, there
are distinctly too many agents that share the secret authinfo values.
It has been
our practice, when taking over operations of registries, to change all authinfo
values.  My instant, kneejerk recommendation upon receiving a dump of data
for a registry is to say, "And we'll be replacing all the authinfos, right?"

I observe that the authinfo values should be considered distinct from user
authentication information for registrars; those are quite different things.  I
see what looks like conflation of the two things downthread.

---

From: "Gould, James" <[email-masked]>
Date: Fri, 14 Dec 2012 15:39:57 +0000

Francisco, 

>From a high-level, independent of the EPP RFC's interpretation that I will
cover below, the description of the <crID> and <upID> elements must
exactly match the description in the EPP RFC's.  The data escrow draft
must not attempt to apply a specific interpretation of the EPP RFC's.

Below is the text from RFC 5731 for the matching <clID>, <crID>, and
<upID> elements of draft-arias-noguchi-dnrd-objects-mapping:

-  A <domain:clID> element that contains the identifier of the
      sponsoring client.

   -  An OPTIONAL <domain:crID> element that contains the identifier of
      the client that created the domain object.

-  An OPTIONAL <domain:upID> element that contains the identifier of
      the client that last updated the domain object.  This element MUST
      NOT be present if the domain has never been modified.

As I pointed out in my past message, the <domain:clID> element references
"sponsoring client" and the <domain:crID> and the <domain:upID> elements
reference simply "client".  The proper interpretation of "sponsoring
client" is to indicate the registrar and the "client" to indicate the
user.  A registry might provide additional tools beyond EPP, like a
Registrar Web Tool, for registrars to manage the objects, where the access
to these tools would require user authentication.  A registry will also
have additional tools and components for authorized internal(registry)
users to make changes like a CSR Web Tool or batches.  The security model
should require different user login credentials per actual user and all
actions taken by that user would be tracked in the system.  If one of the
users created or updated an object, obviously the crDate or upDate should
be set, but the crID or upID fields should be set to the actual user that
took the action.  I'm sure the Registrar would like to know exactly who in
their organization or in the registry created or updated the object.  The
crID and upID fields should reflect the detail of exactly who took the
action.  If the crID and upID fields only referenced the organization, the
registrar would have no way other then reaching out to the registry to
look in their audit tables for the detail of who took the action.  By
linking to the user of the account (registrar or registry) and not
directly to the account for these fields, the registrar and registry
directly knows who took the action without having to scan the audit
records.  The info response would return the detail required via the crID
and upID fields.

Assuming that you do change the text of
draft-arias-noguchi-dnrd-objects-mapping to match RFC 5731 for the <crID>,
and <upID> elements, there is still the open question of what needs to be
deposited for successful recovery by an EBERO provider.  I see the
following options:

1. Include a user deposit that at a minimum would include a user
identifier (e.g. login name) and an account (clID) element.  The account
could be the registrar or registry account.  The crID and upID would link
to the user identifier.
2. Just include the crID and upID as simple strings without any object
references (user or account).  The EBERO provider most likely will not
actually attempt to activate any of the users in the user deposit, so the
crID and upID migrated fields are simply informational and kept to ensure
that the info response is consistent after the transition.  The EBERO
provider would have another set of fields that would properly link to
users (or accounts if that is how their system is built) for future
creates and updates.  If there was any question to who actually created or
updated the object, the EBERO provider would indicate that the user in the
string form was imported from the data escrow that has no additional
information.   

I don't believe referencing the registrar in place of the actual user for
the crID and upID is the intent of the EPP RFC's, but a level of
indirection (user's account) wouldn't be completely out of the question.
The data escrow would then need to support both, meaning that option #2
above would be the only real option.  In any case as stated in my first
sentence above, the description of the <crID> and <upID> elements in
draft-arias-noguchi-dnrd-objects-mapping must match the description of
those fields in the EPP RFC's.

-- 

JG

James Gould
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 12/13/12 1:31 PM, "Francisco Obispo" <[email-masked]> wrote:

>I find myself in this situation more ofter than I would like, but it is
>my job to do fine grain review, and you guys have a better view because
>Verisign played an important role in the authorship of the docs, which is
>why I come to these lists to try to get clarification to those grey areas.
>
>
>>  The
>My design choice would be to keep the changes done by the registry
>somewhere else and not on these fields since in my opinion, they relate
>to authorized clients (a registry/system user might belong to a client),
>so in your example, it is important that 'verisign' did it and not
>jgould, jgould would be referenced in an audit table as a person acting
>on behalf of verisign performing a specific transaction in the logs.
>
>Regards,
>
>
>Francisco Obispo

---

From: Francisco Obispo <[email-masked]>
Date: Fri, 14 Dec 2012 09:45:05 -0800

Hi James,

I don't agree with your interpretation to me it looks more like:

clID -> Sponsoring Client
crID -> Client who was sponsoring at the time of creation
upID -> Client who was sponsoring when the last update occurred

The details of who (which user) updated what, to me is outside the scope of the EPP protocol, I'm not saying it's not important from the registry's perspective.

Our system also has tools like the one you mentioned, for example, the Registrar Web Interface provides the means for registrars to have multiple account with different roles associated with them, and even though we keep detail accounting of who does what, the operations on the SRS are done via the 'role' account, not the individual.

We as a registry are capable of answering a question who did what, from where and at what time.

The interpretation has to do with functionality. If there was a problem with "documentation" lets assume the domain required specific set of paperwork (physical), as the current sponsor (not who created domain), I could look at the <crID> and ask for the paperwork, or if an update occurred that seemed inappropriate in the past, I could also call the <upID> and ask for information. 

Sharing the detail of which individual user (not the registrar or registry org) who performed the [create|update] operation seems useless for me because as an EBERO I would not have that information/nor will need it for anything useful.

Francisco

Francisco Obispo

---

From: "Gould, James" <[email-masked]>
Date: Fri, 14 Dec 2012 18:01:13 +0000

Francisco,

You are adding text to the RFC that doesn't exist.  If the intention was
to include the "sponsoring client" or "registrar" it would have stated it,
but it does not.  You can't simply add text that doesn't exist and then
include that text in a data escrow draft that is based on your
interpretation.  We can agree to disagree on this one, but in either event
you need to change the description of the field in
draft-arias-noguchi-dnrd-objects-mapping to match the RFC to support both
interpretations.  "Client" in our system means user and in your system and
James's system it means registrar.  The data escrow should correctly
capture the data stored by the registry and not attempt to normalize it to
some interpretation that does match the RFC.

The usefulness of the information for an EBERO provider is a separate
topic from the interpretation of the EPP RFC's.  We would need to come to
an agreement with how these elements should be handled (e.g. user deposit,
simple string) by the EBERO provider.

-- 

JG

James Gould
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 12/14/12 12:45 PM, "Francisco Obispo" <[email-masked]> wrote:

>The details of who (which user) updated what, to me is outside the scope
>of the EPP protocol, I'm not saying it's not important from the
>registry's perspective.
>
>Our system also has tools like the one you mentioned, for example, the
>Registrar Web Interface provides the means for registrars to have
>multiple account with different roles associated with them, and even
>though we keep detail accounting of who does what, the operations on the
>SRS are done via the 'role' account, not the individual.
>
>The interpretation has to do with functionality. If there was a problem
>with "documentation" lets assume the domain required specific set of
>paperwork (physical), as the current sponsor (not who created domain), I
>could look at the <crID> and ask for the paperwork, or if an update
>occurred that seemed inappropriate in the past, I could also call the
><upID> and ask for information.
>
>Sharing the detail of which individual user (not the registrar or
>registry org) who performed the [create|update] operation seems useless
>for me because as an EBERO I would not have that information/nor will
>need it for anything useful.
>
>Francisco
>
>

---

From: Francisco Obispo <[email-masked]>
Date: Fri, 14 Dec 2012 10:10:56 -0800

On Dec 14, 2012, at 10:01 AM, "Gould, James" <[email-masked]> wrote:

> but it does not.

The problem is, that it doesn't say it's a user either, it says "client", and you could ask yourself, who is the "client" of an EPP service ? we can't assure a registrar, because in a registry model without registrars' it could be the registry or anyone.

>  You can't simply add text that doesn't exist and then
> interpretation.  

I did not added any text, it was my interpretation.

> We can agree to disagree on this one, but in either event
> James's system it means registrar.

That would be Francisco Arias (ICANN) or Shoji Noguchi (JPRS).

>  The data escrow should correctly

Well actually it is not, it is what we're trying to discuss here, we are trying to figure out how to make the Data escrow system work for Internet Registries.

Francisco

Francisco Obispo

---

From: Francisco Obispo <[email-masked]>
Date: Fri, 14 Dec 2012 10:29:22 -0800

>> include that text in a data escrow draft that is based on your

BTW, the fact that Arias, and Noguchi decided to use the EPP format as a guideline, is plausible, but if you are correct but what is needed is the registrar/client and not the individual user information, then the requirement in the escrow needs to reflect what is needed and not what the EPP protocol says.

I'm just trying to say that one protocol is not bound to the other, and if that was the case, we would not be discussing XML over CSV or viceversa.

Francisco Obispo

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 14 Dec 2012 18:29:53 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francisco Obispo
> Sent: Friday, December 14, 2012 1:11 PM
> To: Gould, James
> Cc: Luis Muñoz; [email-masked]
> > You are adding text to the RFC that doesn't exist.  If the intention
> > was to include the "sponsoring client" or "registrar" it would have
> > stated it, but it does not.
> 
> The problem is, that it doesn't say it's a user either, it says
> "client", and you could ask yourself, who is the "client" of an EPP
> service ? we can't assure a registrar, because in a registry model
> without registrars' it could be the registry or anyone.

The EPP fields are intended to capture the value of the <clID> element provided with the <login> command of the client (in the context of a client-server relationship) that performed the create or update action. The clID, crID, and upID values don't tell you anything about the client's role.

Scott

---

From: "Gould, James" <[email-masked]>
Date: Fri, 14 Dec 2012 18:31:43 +0000

Francisco,

My replies are below.

-- 

JG

James Gould
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 12/14/12 1:10 PM, "Francisco Obispo" <[email-masked]> wrote:

>The problem is, that it doesn't say it's a user either, it says "client",
>and you could ask yourself, who is the "client" of an EPP service ? we
>can't assure a registrar, because in a registry model without registrars'
>it could be the registry or anyone.

The client is the user that is interfacing with the system (web UI user,
EPP user, batch user).  All user's of a registrar and registry are clients
to the service and should be reflected in the crID and upID.  We only
support a single user of the registrar to interface with the EPP service,
but that user (B2B) is still separate and distinct from the Registrar
itself.  We support many users via the other channels.

>I did not added any text, it was my interpretation.

I'm referring to adding text to the data escrow draft that doesn't match
the EPP RFC.

>That would be Francisco Arias (ICANN) or Shoji Noguchi (JPRS).

That would also include Gustavo I assume.  My feedback is that the text
needs to match the EPP RFC.  Gustavo, can you or one of your co-authors
make that change?  

>Well actually it is not, it is what we're trying to discuss here, we are
>trying to figure out how to make the Data escrow system work for Internet
>Registries.

Yes, now that we know that user's do exist in registry data models, the
question is whether they need to be escrowed along with the registrar
information?  If so, what attributes need to be escrowed?  If not, what do
we do with the crID and upID fields that "in some systems" reference users
and not registrars.

>>>> took the action.  I'm sure the Registrar would like to know exactly
>>>>who
>>>> in
>>>> creates and updates.  If there was any question to who actually
>>>>created
>>>> or
>>>>> Verisign played an important role in the authorship of the docs,
>>>>>which
>>>>> is
>>>>>> term client is generic, where the reference to the "sponsoring
>>>>>>client"
>>>>>> in
>>>>> Yes, but my interpretation is that those fields track 'registrars'
>>>>>not
>>>>> internal users.
>>>>> 
>>>>> 
>>>>> 
>>>>>> the sponsoring client information for the crID and upID fields,
>>>>>>since
>>>>>> they
>>>>> 2) Domain name is transferred to REGISTRAR_B (clID = REGISTRAR_B
>>>>>crID =
>>>>> REGISTRAR_A)
>>>>>> interpretation of the EPP specification as it relates to the crID
>>>>>>and
>>>>>> upID
>>>>>> elements.  
>>>>>

---

From: Francisco Obispo <[email-masked]>
Date: Fri, 14 Dec 2012 10:33:53 -0800

> The EPP fields are intended to capture the value of the <clID> element provided with the <login> command of the client (in the context of a client-server relationship) that performed the create or…

So clID -> Sposoring Client, which means: a user that was able to login via an EPP <login> command, which is consider to sponsor the domain name right?

Which means that crID == clID that registered the domain name

and

upID => clID that last updated the domain name

I don't see any ambiguity here.

Francisco Obispo

---

From: "Gould, James" <[email-masked]>
Date: Fri, 14 Dec 2012 18:45:04 +0000

Francisco,

EPP is the provisioning protocol for the systems that you are going to
escrow, so naturally it is the basis in determining the set of fields and
intent of the fields to escrow.  I don't believe you can separate the two
in the discussion. 

-- 

JG

James Gould
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 12/14/12 1:29 PM, "Francisco Obispo" <[email-masked]> wrote:

>BTW, the fact that Arias, and Noguchi decided to use the EPP format as a
>guideline, is plausible, but if you are correct but what is needed is the
>registrar/client and not the individual user information, then the
>requirement in the escrow needs to reflect what is needed and not what
>the EPP protocol says.
>
>I'm just trying to say that one protocol is not bound to the other, and
>if that was the case, we would not be discussing XML over CSV or
>viceversa.
>
>
>Francisco Obispo

---

From: Francisco Obispo <[email-masked]>
Date: Fri, 14 Dec 2012 10:54:30 -0800

On Dec 14, 2012, at 10:31 AM, "Gould, James" <[email-masked]> wrote:

> to the service and should be reflected in the crID and upID.  

For us, we have separate systems: the SRS, which is the authoritative source for registry information, and the Registrar Web Interface, which has the other role accounts. When a user of this system needs to perform an operation in the SRS, we do that with the 'role' account credentials, not the individual user, because SRS doesn't know about the users of this other system.

> We only

We do that as well, and we supported as described above.

Regards,

Francisco Obispo

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 14 Dec 2012 18:57:46 +0000

> From: Francisco Obispo [mailto:[email-masked]]
> Sent: Friday, December 14, 2012 1:34 PM
> To: Hollenbeck, Scott
> Cc: Gould, James; [email-masked]
> > The EPP fields are intended to capture the value of the <clID>
> element provided with the <login> command of the client (in the context
> of a client-server relationship) that performed the create or update
> action. The clID, crID, and upID values don't tell you anything about
> the client's role.
> 
> So clID -> Sposoring Client, which means: a user that was able to login
> via an EPP <login> command, which is consider to sponsor the domain
> name right?

EPP doesn't refer to clients as "users" since that word has anthropomorphic meaning and clients don't have to be human. It does say this about the "sponsor" word (in section 1.1 of RFC 5730):

"A protocol client that is authorized to manage an existing object is described as a "sponsoring" client throughout this document."

Scott

---

From: Francisco Obispo <[email-masked]>
Date: Fri, 14 Dec 2012 11:01:18 -0800

Yes,

I mentioned in a previous email that "registrar" was also wrong, because we're assuming that there is one, when it could be anyone.

I agree with the concept of "Client" but I just want to make sure we're referring to the same type of client across upID, crID and clID.

So if a "client" was able to login via EPP, that ID will be reflected in any of those fields in the corresponding object's information as part of a transaction that occurred.

So when exporting the data to the escrow, those fields must include an identifier that is present in the "client"'s table, and if clients happen to be registrar, it will be a registrar ID.

Francisco

Francisco Obispo