Page History
...
For other times: https://tinyurl.com/yb9cb8nn
Info |
---|
PROPOSED AGENDA . Upon your review of the workbooks (attached), you’ll likely see that we’ll probably need at least two more meetings to work these into final shape for the Final Report. Please consider some possible times you may be available this week and next. Apologies for the length of this email. Attached is Annex D of the draft Final Report that contains the following high-level changes in redline from the Initial Report:
What are the key activities this small-team should accomplish?
What is out-of-scope for the small-team?
Other key tasks:
For the first meeting: 1) Welcome and Intro 2) A quick review of changes to Annex D made from the Initial Report 3) A discussion of the small team’s approach and other ideas/requirements based from the public comment(s) that suggest this review 4) A review of input received from Francisco based on a technical perspective (may align to some of the logic concerns from RySG) 5) Mostly circle around the logic discussions around Purpose 1 and 2 6) Quick review of consolidated data elements by processing activity charts (updates started, but depends on updates to workbooks) BACKGROUND DOCUMENTS |
Info | ||
---|---|---|
| ||
Tip | ||
---|---|---|
| ||
Apologies: none |
Note | ||
---|---|---|
Notes/ Action Items Agenda: 1) Welcome and Intro
2) A quick review of changes to Annex D made from the Initial Report
3) A discussion of the small team’s approach and other ideas/requirements based from the public comment(s) that suggest this review ***Below you will see in RED actions/response to Francisco’s input to the data elements. Virtually all of these have been imported into the attached Annex D either via redline suggested change or a comment or both for the team to consider. Lastly, I will be forward this email to the main list to announce the scheduling of this call and allow for others interested to join, given that not all were present in Toronto.
Please see below additional input:
BAC: Updated in workbooks, will be updated in Final Report
BAC: Updated in workbooks, will be updated in Final Report; comment made in Purpose 1 workbook to be reviewed by small team as this was formerly marked as Required.
BAC: Updated in workbooks, will be updated in Final Report; ; comment made in Purpose 1 workbook to be reviewed by small team as this was formerly marked as Required.
BAC: Updated in workbooks as footnote, will be updated in Final Report: The field will now be listed as “Domain Status(es)”
BAC: Yes, that is the intent.
BAC: Updated in workbooks, will be updated in Final Report: The field will now be listed as “NameServer(s)”
BAC: Updated in workbooks, will be updated in Final Report: Question: Just to confirm, if I were perform a RDDS query at the Registrar, these three fields will not be displayed?
BAC: Added as footnote on Purpose 1 table
BAC: Updated in workbooks, will be updated in Final Report:
BAC: Updated in workbooks, will be updated in Final Report:
BAC: Updated in workbooks, will be updated in Final Report:
BAC: Updated in workbooks, will be updated in Final Report:
BAC: Added as footnote on Purpose 1 table
BAC: Updated in workbooks, will be updated in Final Report:
BAC: Updated in workbooks, will be updated in Final Report:
BAC: Agreed on the preference, and that is why Purpose 4 is split into two workbooks 4A-Registrar, 4B Registry. I think for the purpose of the Final report, we should remove the brown consolidated table, and create a distinct table for the Rr and Ry, representing the specific data fields transferred to the Escrow Provider. This will be flagged for the small team review.
BAC: Added footnote to Purpose 4B workbook, we’ll add to Final Report’s recommendations section upon executing #16 above.
BAC: Added comment to Purpose 4B workbook to address with small team.
BAC: This will be addressed in #16 above; confirmed that Purpose 4B workbook properly transfers this field, while the 4A workbook does not.
BAC: This can be addressed in #16 above?
BAC: Confirmed. This table should be updated. I flagged in the Purpose 2 workbook for the small team to confirm these two fields. “Registry Registrant ID” shows disclosed and redacted. However, “Tech ID” is not designated as being disclosed. The consolidated data elements table also has this flagged to be addressed.
BAC: Being considered by EPDP Plenary, substantial changes deliberated in Toronto that will changes the recommendation language from the Initial Report.
BAC: Retention is still an active issue under deliberation by the EPDP. The small team will also examine the logic of retention across each of the 7 purposes, by role. Purpose 1 workbook contains the Processing Activity and data elements that will be retained, but it is implied that it is both for Registrars and Registries. Should two Processing Activities in the workbook be created to distinguish and Rr and Ry retention tag? Recommendation 11 only mentions Registrars, should it also include Registries (or via a distinct recommendation?)
BAC: Retention is still an active issue under deliberation by the EPDP.
BAC: Added as issue to address in small team review of workbooks. BACKGROUND DOCUMENTS | ||
Info | ||
| ||
Tip | ||
|
Team Discussion
High-level Summary of Changes
Francisco List
5) Mostly circle around the logic discussions around Purpose 1 and 2 6) Quick review of consolidated data elements by processing activity charts (updates started, but depends on updates to |
Note |
---|
Notes/ Action Items |