[Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019

Janis Karklins karklinsj at gmail.com
Mon Oct 21 10:48:01 UTC 2019


Volker,

I had impression that the principle that "SSAD should be as much automated
as possible and standardized for the rest" was agreed by all groups in the
Team already a while ago.

When we are thinking about implementability and scaleability of the system,
ambiguities in formulations may not be helpful. I understand that on some
issues groups may have divergent or even opposing opinions. We should be as
flexible as possible and as precise as possible and look at the SSAD as a
package of different compromises by all groups.

JK

On Mon, Oct 21, 2019 at 2:45 AM Volker Greimann <vgreimann at key-systems.net>
wrote:

> Hi Alex,
>
> thank you for your response. I don't think that anyone opposes the idea
> that certain aspects of the system can and should be automated, however
> that is not the general usage of the term in this group so far. "To
> automate" was always discussed in the context of automating the disclosure
> decision, and in that context, we cannot support this language.
>
> I think it would be helpful if we were all more clear in what we mean when
> we use certain words.
>
> Automating completeness, error checking and notices of receipt makes sense
> and it would be very much appreciated if the system takes care of that for
> us, but that is not what we mean by "automation".
>
> To your last points, I think we have established that all requests will
> likely be those of the 6.1.f. variety, and those all include that notorious
> balancing test which needs to take into consideration facts that are not
> part of the request and in my view cannot be automated.
>
> My personal position on this is that this point can be left open:
>
> If a disclosing CP feels that they can automate that part as well, they
> should be able to do so, but we should not mandate it. So by striking the
> reference at this point, we do not prohibit such automation, but we also do
> not mandate it. That strikes me as a workable compromise between our
> positions, won't you agree?
>
> Best,
>
> Volker
> Am 20.10.2019 um 19:02 schrieb Alex Deacon:
>
> Volker and all,
>
> Our thoughts on the topic of automation.
>
> The IPC objects to any policy that does not allow for the automation of
> request/response processing.    Once again I remind everyone we are
> defining policy for a *system* that will be RDAP based - not a process that
> is based on "old fashioned" technology like smoke signals, wax sealed
> correspondence written by quill and ink, telex messages, faxes or email.
> (We already did this in Phase 1 Rec 18)
>
> Clearly we want a policy that allows for the automation of syntax checking
> of incoming requests, resulting in an automatic response that indicates the
> errors to the requestor.   This automation addresses the risk of filling up
> the request queues of the discloser with malformed requests.
>
> Clearly we want a policy that allows for the automation of checking that
> the contents of a request is complete, based on policy we are setting in
> another building block, resulting in an automatic response that details
> what is be missing (per policy).    This automation allows for the
> discloser to indicate - without human intervention - what additional
> information is required per policy and enables the requestor to address the
> error.
>
> Clearly we want a policy that allows for the automation of an immediate
> and synchronous response that indicates the receipt of a valid request and
> some indication that it will be processed.   Typically such responses
> include a "ticket number" or some kind of uniqueID to allow for future
> queries (status, updates, deletion, etc.).   This automation allows for
> efficient queue management on the disclosers side and assists in ensuring
> our principal of "predictability" is met for the requestor.
>
> It is important to note that in none of the three points above do I state
> or even suggest that automation will or can result in the automatic
> response of non-public data.
>
> However having said that - there is no doubt in my mind that there will
> exist some subset of well formed, valid, complete, properly identified and
> accredited requests for some subset of legal basis and some subset of
> purposes that indeed can be automatically processed and result in the
> disclosure of non-public RDS data without human intervention.    The IPC
> would object to any policy language that would explicitly forbid this from
> ever happening.
>
> Thanks.
> Alex
> ___________
> *Alex Deacon*
> Cole Valley Consulting
> alex at colevalleyconsulting.com
> +1.415.488.6009
>
>
>
> On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann <vgreimann at key-systems.net>
> wrote:
>
>> Hi Caitlin,
>>
>> I don't think 4.B) Principle B:
>>
>>    - What does accreditation mean? The group discussed the potential for
>>    allowing for the automatic disclosure where allowed under the law suggest
>>    “and automation of responses where possible under applicable law”
>>
>> truly captures the content of our disscussion. The draft should only
>> contain agreed language and the inclusion of "and automation of" was very
>> much not agreed. In fact this language was opposed by a large group and
>> therefore should be removed unless approved.
>>
>> --
>> Volker A. Greimann
>> General Counsel and Policy Manager
>> *KEY-SYSTEMS GMBH*
>>
>> T: +49 6894 9396901
>> M: +49 6894 9396851
>> F: +49 6894 9396851
>> W: www.key-systems.net
>>
>> Key-Systems GmbH is a company registered at the local court of
>> Saarbruecken, Germany with the registration no. HR B 18835
>> CEO: Alexander Siffrin
>>
>> Part of the CentralNic Group PLC (LON: CNIC) a company registered in
>> England and Wales with company number 8576358.
>>
>>
>> On Fri, Oct 18, 2019 at 1:17 AM Caitlin Tubergen <
>> caitlin.tubergen at icann.org> wrote:
>>
>>> Dear EPPD Team:
>>>
>>>
>>>
>>> Please find below the notes and action items from today’s EPDP Team
>>> meeting.
>>>
>>>
>>>
>>> The next EPDP Team meeting will be *Tuesday, 22 October* at 14:00 UTC.
>>>
>>>
>>>
>>> Best regards,
>>>
>>>
>>>
>>> Marika, Berry, and Caitlin
>>>
>>>
>>>
>>> *EPDP Phase 2 - Meeting #25*
>>>
>>> *Proposed Agenda*
>>>
>>> Thursday, 17 October 2019 at 14.00 UTC
>>>
>>>
>>>
>>> *Action Items*
>>>
>>>    1. Support Staff to update the text of the Accreditation Building
>>>    Block
>>>    <https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E/edit>
>>>    and Financial Sustainability Block
>>>    <https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit>
>>>    based on today’s discussion.
>>>    2. EPDP Team to provide additional edits in the Accreditation
>>>    Building Block
>>>    <https://docs.google.com/document/d/1zAEBygpoddKOJOfb1whMtaQHcik856aZZc9BoDk392E/edit>
>>>    re: implementation guidance and definitions by COB tomorrow, *Friday,
>>>    18 October*.
>>>    3. EPDP Team to provide additional edits from today’s conversation
>>>    to the Financial Sustainability Block
>>>    <https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit>
>>>    by *Friday, 18 October*.
>>>    4. EPDP Volunteers needed to propose initial text for Building Block
>>>    M – Terms of Use/Disclosure Agreements/Privacy Policies
>>>    <https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit>
>>>    by *Monday, 21 October*.
>>>
>>> 1.                            Roll Call & SOI Updates (5 minutes)
>>>
>>>
>>>
>>> 2.                            Confirmation of agenda (Chair)
>>>
>>>
>>>
>>> 3.                            Welcome and housekeeping issues (Chair)
>>> (5 minutes)
>>>
>>> a)                      Update from legal committee
>>>
>>> b)                     Status of building blocks
>>> <https://community.icann.org/x/k5ICBw>
>>>
>>> 4.                            Accreditation
>>> <https://docs.google.com/document/d/1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4YnHY/edit>
>>> (building block f and j) – second reading continued (30 minutes)
>>>
>>> a)                      Overview of implementation guidance section
>>>
>>> b)                     Feedback from EPDP Team
>>>
>>> Principle b
>>>
>>>    - Requirements should be spelled out as part of the policy discussion
>>>    - There will be different types of entities and may have different
>>>    documentation to provide
>>>    - These requirements should be as uniform as possible
>>>    - C may need to come before B
>>>    - There needs to be an underlying baseline of requirements that are
>>>    uniform.
>>>    - Accreditation is all about identification; thought the group
>>>    agreed that accreditation is at a minimum about identity, but it could also
>>>    establish other things as well – such as law enforcement, cyber security,
>>>    etc.
>>>    - It would be helpful to draw a line b/w the accreditation process
>>>    and what needs to be included in the disclosure request – parties seeking
>>>    accreditation should probably not have to include every scenario where a
>>>    law enforcement would have to interface with the SSAD – hoping the Team can
>>>    be more specific with baseline requirements for accreditation
>>>    - Law enforcement will likely have a different accreditation system
>>>    than other entities, so that conversation should be separate
>>>    - What does accreditation mean? The group discussed the potential
>>>    for allowing for the automatic disclosure where allowed under the law
>>>    suggest “and automation of responses where possible under applicable law”
>>>    - Accreditation does not equate to automated response by default –
>>>    each query will be decided upon on its own merits
>>>    - Certain types of people (user groups) may allow for streamlining –
>>>    some categories may involve more scrutiny – to that extent, accreditation
>>>    is more than authentication of identity
>>>    - By adding too much into one subject, the discussion is encumbered.
>>>    The discussion of accreditation and authentication should be decoupled.
>>>    - The small team for accreditation agreed that accreditation is not
>>>    authorization. It might be desirable and helpful to have attributes
>>>    associated with accreditation. The only attribute that will consistently
>>>    make a difference is whether it is law enforcement or not. With respect to
>>>    cyber security researchers, any IT person could legitimately claim to be
>>>    doing cyber security research. There shouldn’t be entry barriers that say
>>>    you are or are not cyber security researchers.
>>>    - The building block includes a list of definitions, which the Team
>>>    has not yet discussed.
>>>    - If accreditation only proves identity, the Team is limiting what
>>>    it can discuss with regard to the release of data.
>>>    - Support Staff to try to analyze what was said during the
>>>    conversation with respect to Subpoint B and Subpoint C for online
>>>    consideration
>>>
>>> Principle d
>>>
>>>    - What is the expectation for what de-accreditation means?
>>>    - Accreditation would be that the accreditation is who they say they
>>>    are; as a result, there is access to the system without further
>>>    verification of identity. If an entity is de-accredited, it would need to
>>>    be re-accredited.
>>>    - This would mean that the authority could revoke access to the
>>>    system, not “de-accredit”.
>>>
>>> Principle g
>>>
>>>    - What is the accreditation policy and requirements – where is this?
>>>    - The accreditation policy and associated requirements have not been
>>>    drafted/implemented yet
>>>
>>> Principle i
>>>
>>>    - Issue with replaced “must be paid for service” with “cost-recovery
>>>    system” – this could suggest that the costs need to be covered by another
>>>    form. The whole system is for the benefit of third-party users who would
>>>    request disclosure of registration data – concerned with costs being
>>>    shifted to registrants
>>>    - Two types of costs involved – development and deployment of the
>>>    system and then the cost of day-to-day running of the system
>>>    - The costs need to be considered in a cost-recovery system. The
>>>    purpose of accreditation is to lower these costs. Whatever cost-recovery
>>>    system takes place – these costs need to be recovered from the users of the
>>>    system, not from registrants or contracted parties.
>>>    - Have issues with the terms “significantly reduce”. This is a
>>>    separate system. The Team really needs to consider a cost-benefit analysis
>>>    of figuring out someone’s ID – how much will this actually cost? Is it
>>>    achievable?
>>>    - Perhaps the second sentence could be moved to Block N.
>>>    - There are two sets of development costs – accreditation system and
>>>    SSAD. This paragraph should be limited to the development of the
>>>    accreditation system. Re: development of SSAD – that should be moved to
>>>    Building Block N.
>>>    - Agree with moving the second sentence to Building Block N. If the
>>>    benefit exceeds the cost, there needs to be an escape valve in the policy.
>>>    As a policy principle, it should be the benefits of the SSAD system must
>>>    outweigh the costs.
>>>    - If there are too many requirements, the system will be too
>>>    expensive. Avoid saying the costs outweigh the benefits. This language
>>>    needs more work to make it clear what the team is after.
>>>    - Maintain first sentence and delete second sentence
>>>    - This conversation can be moved to the financial building block.
>>>    - Registrants do get something from the SSAD – a reliable and secure
>>>    DNS. The SSAD is not a clean slate – the current system is the registrars
>>>    having to do the work themselves, and someone is paying for this.
>>>    - There is a clean and reliable DNS system today – to say “cleaner”
>>>    and “more reliable” would be preferable. Costs may be occurring in other
>>>    areas that are offset for a system that doesn’t currently exist is
>>>    problematic and disproportionate.
>>>
>>> Principle k
>>>
>>>    - The use of the word “tagging” is confusing
>>>    - Marc to submit proposed updated online
>>>    - What is the meaning b/w the first and second sentence?
>>>    - The SSAD takes requests from accredited and unaccredited users, so
>>>    unaccredited users will be treated a different way. RDAP is a query
>>>    response protocol, where you query the system and get a response back.
>>>    There will now be instances where some queries will be responded to right
>>>    away and others will be queued (for balancing tests have to be conducted)
>>>    and the response will be returned later – RDAP was not designed to be used
>>>    in this way.
>>>    - The second sentence in k does not make sense.
>>>
>>> Implementation Guidance Feedback
>>>
>>>    - Drafting note c – legitimate and lawful purpose described above
>>>    (stated)
>>>    - Some implementation belongs in the policy – a and b could be left
>>>    in implementation guidance. C and D could be left in the policy language as
>>>    opposed to implementation guidance.
>>>    - De-accreditation – this will depend on what the specifics of
>>>    accreditation are and what it would mean for someone to be de-accredited
>>>    - At the F2F, the Team talked about de-accreditation for the users
>>>    of the system and the accrediting entities. E and G are potentially in
>>>    conflict with each other.
>>>    - What does access to the system mean? Even bad actors should have
>>>    access to the public data.
>>>    - This hinges on unaccredited users having access to the system – is
>>>    the SSAD being used by everyone, or just accredited users?
>>>    - Can the Team agree that the SSAD could be used by both accredited
>>>    and non-accredited users? The difference is that accredited entities will
>>>    query the system w/o verification of the entity.
>>>    - SSAD should be usable by everyone and not exclude anyone
>>>    - How one does identity verification is a decision ICANN should be
>>>    making in the public interest.
>>>    - Concern that individuals should not be prevented from getting
>>>    access to data they may need to protect their domain name
>>>
>>>
>>>
>>> c)                      Confirm next steps
>>>
>>>    - Support Staff to update the text of the Accreditation Building
>>>    Block based on today’s discussion. EPDP Team to provide additional edits in
>>>    the Google Doc for implementation guidance and definitions by COB tomorrow,
>>>    Friday, 18 October.
>>>
>>> 5.                            Financial Sustainability
>>> <https://docs.google.com/document/d/1Ci-wvA1P9yoKjJ5DPeRbZ5FOHL2D8ExGsN2SV9TPELM/edit>
>>> (building block n) – second reading
>>>
>>> a)                      Overview of updates made following first reading
>>>
>>> b)                     Feedback from EPDP Team
>>>
>>>
>>>
>>>    - Third paragraph: cost-recovery basis is used in multiple places.
>>>    The Team needs to define this term. Cost-recovery is a term of art in
>>>    accounting, and that definition is probably not what the Team meant here.
>>>    - Cost recovery may mean different things to different people. Also,
>>>    what does “historic costs” mean in this context? The users of the system
>>>    should be sustaining the capability of the system on an ongoing basis.
>>>    - Second paragraph – object to contracted parties bearing the costs.
>>>    - Different parties will bear different costs – this language does
>>>    not explain that division of responsibilities. For example, accredited
>>>    entities will bear the costs of getting accredited. The parties who are
>>>    receiving the queries that contracted parties would be responsible for
>>>    setting up their systems to receive queries and respond to them.
>>>    - Registrants being beneficiaries of the system may be a tenuous
>>>    argument
>>>    - Fourth paragraph – in favor or usage-based fees that sustain the
>>>    operation of this system.
>>>    - A system cannot be costed out unless we know what the system is
>>>    designed to do.
>>>
>>> c)                      Confirm next steps
>>>
>>>
>>>
>>> 6.                            Terms of use / disclosure agreements /
>>> privacy policies
>>> <https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit>
>>> (building block m) – first reading
>>>
>>> a)                      Review building block
>>>
>>> b)                     Feedback from EPDP Team
>>>
>>> c)                      Confirm next steps
>>>
>>>
>>>
>>> 7.                            Wrap and confirm next EPDP Team meeting
>>> (5 minutes):
>>>
>>> a)                      Tuesday 22 October 2019 at 14.00 UTC
>>>
>>> b)                     Confirm action items
>>>
>>> c)                      Confirm questions for ICANN Org, if any
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Gnso-epdp-team mailing list
>>> Gnso-epdp-team at icann.org
>>> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
>>> _______________________________________________
>>> By submitting your personal data, you consent to the processing of your
>>> personal data for purposes of subscribing to this mailing list accordance
>>> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy)
>>> and the website Terms of Service (https://www.icann.org/privacy/tos).
>>> You can visit the Mailman link above to change your membership status or
>>> configuration, including unsubscribing, setting digest-style delivery or
>>> disabling delivery altogether (e.g., for a vacation), and so on.
>>
>> _______________________________________________
>> Gnso-epdp-team mailing list
>> Gnso-epdp-team at icann.org
>> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
>> _______________________________________________
>> By submitting your personal data, you consent to the processing of your
>> personal data for purposes of subscribing to this mailing list accordance
>> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
>> the website Terms of Service (https://www.icann.org/privacy/tos). You
>> can visit the Mailman link above to change your membership status or
>> configuration, including unsubscribing, setting digest-style delivery or
>> disabling delivery altogether (e.g., for a vacation), and so on.
>
> --
> Volker A. Greimann
> General Counsel and Policy Manager
> *KEY-SYSTEMS GMBH*
>
> T: +49 6894 9396901
> M: +49 6894 9396851
> F: +49 6894 9396851
> W: www.key-systems.net
>
> Key-Systems GmbH is a company registered at the local court of
> Saarbruecken, Germany with the registration no. HR B 18835
> CEO: Alexander Siffrin
>
> Part of the CentralNic Group PLC (LON: CNIC) a company registered in
> England and Wales with company number 8576358.
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
> the website Terms of Service (https://www.icann.org/privacy/tos). You can
> visit the Mailman link above to change your membership status or
> configuration, including unsubscribing, setting digest-style delivery or
> disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20191021/a49879ea/attachment-0001.html>


More information about the Gnso-epdp-team mailing list