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

[Francisco Obispo <[e-mail]>]

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

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

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
> include that text in a data escrow draft that is based on your
> interpretation.  

I did not added any text, it was my 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.

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


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

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


> -- 
> 
> JG
> 
> 
> 
> James Gould
> Principal Software Engineer
> [e-mail]
> 
> 703-948-3271 (Office)
> 12061 Bluemont Way
> Reston, VA 20190
> VerisignInc.com
> 
> 
> 
> 
> 
> 
> 
> On 12/14/12 12:45 PM, "Francisco Obispo" <[e-mail]> wrote:
> 
>> 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
>> 

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