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

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

Francisco,

My replies are below.


-- 

JG
 

 
James Gould
Principal Software Engineer
[e-mail]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com







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

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

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.


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

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

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

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?  

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

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.



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