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

[Francisco Obispo <[e-mail]>]

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


On Dec 14, 2012, at 7:39 AM, "Gould, James" <[e-mail]> wrote:

> 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
>> 

Francisco Obispo 
Director of Applications and Services - ISC
email: [e-mail]
Phone: [phone] || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE