[Gnso-epdp-team] Notes and action items - EPDP Meeting #25 - 17 Oct 2019
Volker Greimann
vgreimann at key-systems.net
Mon Oct 21 11:25:08 UTC 2019
Hi JK,
we are not disagreeing here, I think, just trying to clarify our
understanding. I also agree to that principle.
Best,
Volker
Am 21.10.2019 um 12:48 schrieb Janis Karklins:
> 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 <mailto: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 <mailto:alex at colevalleyconsulting.com>
>> +1.415.488.6009
>>
>>
>>
>> On Fri, Oct 18, 2019 at 1:01 PM Volker Greimann
>> <vgreimann at key-systems.net <mailto: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 <http://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
>> <mailto: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 <mailto: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 <mailto: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 <http://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 <mailto: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20191021/1c0ddf4b/attachment-0001.html>
More information about the Gnso-epdp-team
mailing list