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

["Gould, James" <[e-mail]>]

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
Principal Software Engineer
[e-mail]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com







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

>
>
>
>
>On Dec 13, 2012, at 9:42 AM, "Gould, James" <[e-mail]> 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
>> 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.
>
>Yes, but my interpretation is that those fields track 'registrars' not
>internal users.
>
>
>
>> 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.
>
>
>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
>> 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.  
>
>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 
>Director of Applications and Services - ISC
>email: [e-mail]
>Phone: [phone] || INOC-DBA *3557* NOC
>PGP KeyID = B38DB1BE
>