Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Info

PROPOSED AGENDA


0. Sanity Check on work to date
1. Quick Review through Purposes 1-3
2. Detailed Review of Purpose 4-7
3. Review of consolidated data element tables
4. Thursday call?

BACKGROUND DOCUMENTS



Info
titleRECORDINGS

Mp3

Adobe Connect Recording

Tip
titlePARTICIPATION

Attendance & AC chat

Apologies: Sarah WyldKurt Pritz

 

Note

Notes/ Action Items


Notes


Question: is the logic more clear in terms of the processing activities? Are the new designations in the data elements tables more clear?


  • Generally speaking, yes
  • Some of the data elements themselves may need to change


1A


How will in-zone IP address be documented? Is this optional that a registrant will supply this, or is this optional for registry? If it is optional for registry, what does this look like?


  • If registry supports in zone hosts, if would be required for registry to support it, but optional for Rts to provide.
  • IP address of the nameservers - those are attributes of the nameserver object, not the domain name object.
  • For more registry operators, nameservers are standalone objects.
  • In legacy WHOIS, there are three types of look-ups, and nameserver look-ups are separate lookups


Proposal: under transmission column, it's optional CP for contracted party, and the following footnote would be added:  if in zone hosts are supported, it is optional for the Registrant to provide it, but required for the Registry to support it if it is supplied.


1B


  • Where disclosure is envisaged, we may be required to disclose this data for law enforcement. Another disclosure could be applying terms and conditions and sued.
  • Is disclosure to third parties sufficient here?


  • For DNSSEC, yes, optional for RNH to provide, required for registry and support, but also REQUIRED for registry to publish - Berry to reconcile to what is in 1B with 1A.


2


Does retention need to be listed under Purpose 2, or would it mimic the retention as listed under Purpose 1A and 1B?


  • We should not have retention for this purpose.
  • In the absence of a law dictating a time period for retention, there is no retention for this purpose.


3


Start thinking about what kind of rationale would go under lawful basis for these two cells. Also, come up with an appropriate term for what we will call the minimum set of public data.


  • Next Gen RDS group called it "minimum public data set", so that is a preferred option.
  • Is any documentation needed for if data elements, like domain names, could be PII?
  • Could a nameserver be PII? It doesn't matter - b/c publication is necessary to perform the service.


4a and 4b


  • Minimum data set - the data elements are collected for the purpose of escrow as well as <other purposes>.


  • Proposal: the list in 4B as required - anywhere with green or yellow (optional), that would provide all data elements collected by a registrar that would be populated into 4A PA1.


Purpose 5


  • Compliance should not be intertwined with Purpose 2.
  • Waiting for green light from the plenary to make suggested edits by Alan G. re: ARS purpose.


Purpose 6


  • The structure of this workbook is based on UDRP, URS, and TDRP, as the other DRPs have not yet been used.


  • PA -3 - transmission of data to provider
  • If data is transferred to the registry as a passthrough to pass it on to someone else, it is unnecessary to transfer for this purpose