[gnso-rds-pdp-wg] Attendance, Recordings & AC Chat from Next-Gen RDS PDP WG call on Tuesday, 29 August 2017 at 16:00 UTC
Julie Bisland
julie.bisland at icann.org
Tue Aug 29 19:30:51 UTC 2017
Dear All,
Please find the attendance of the call attached to this email, and the Adobe Connect chat, mp3 & Adobe Connect recordings below for the Next-Gen RDS PDP Working group call held on Tuesday, 29 August 2017 at 16:00 UTC.
MP3: http://audio.icann.org/gnso/gnso-nextgen-rds-pdp-29aug17-en.mp3
AC recording: https://participate.icann.org/p1k08nsw9c2/<https://participate.icann.org/p1k08nsw9c2/?OWASP_CSRFTOKEN=92ef84797cbc0a40edc01adc638682d4b8e9db4caddb88df1939c4dc577b4caa>
The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page: http://gnso.icann.org/en/group-activities/calendar<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group-2Dactivities_calendar-23nov&d=DwMF-g&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=PDd_FX3f4MVgkEIi9GHvVoUhbecsvLhgsyXrxgtbL10DTBs0i1jYiBM_uTSDzgqG&m=GJMkY4Fbi9sry9Z53DaSWJm-mHxMfFxg7MEVDf2JU90&s=FI3QJYH6DWWCDQir6NDMSjPkzdqfTTUmf9Ua-AYpc14&e=>
** Please let me know if your name has been left off the list **
Mailing list archives: http://mm.icann.org/pipermail/gnso-rds-pdp-wg/
Wiki agenda page: https://community.icann.org/x/W2fwAw
Thank you.
Kind regards,
Julie
———————————————
AC Chat Next-Gen RDS PDP WG Tuesday, 29 August 2017
Julie Bisland:Welcome to the GNSO Next-Gen RDS PDP Working Group call on Tuesday, 29 August 2017 at 16:00 UTC
Julie Bisland:Agenda wiki page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_XmfwAw&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=QiF-05YzARosRvTYd84AB_UYInlydmFcjNmBM5XgySw&m=Or62BeYmZRtfMAuXRqyOjaoanchxiSNJveLu4T8GB4w&s=fbqyem3qZ7jBBM7lhWQrjCW5C3AEABTNc5lNmQqDfsM&e=
Maxim Alzoba (FAITID):Hello All
Maxim Alzoba (FAITID):@Julie, is it possible to make history of the chat longer?
Maxim Alzoba (FAITID):than usual
Marika Konings:@Maxim - the problem is that changing the size of the chat pod affects the size of the slides.
Chuck Gomes:Hi all
Maxim Alzoba (FAITID):@Marika, I am not talking about the size on the screen , more about size in chars
Julie Bisland:I'll look into it, but I suspect not, Maxim
Maxim Alzoba (FAITID):thanks
Lisa Phifer:@Maxim, you can change the size of the chat font yourself using menu at upper right of chat window
andrew sullivan:I observe that AC seems still sometimes to want to use Flash. Dunno if that is surprising to whichever group operates it.
Ayden Férdeline:hi all
Maxim Alzoba (FAITID):@Lisa, I meant size of the chat history in chars
Lisa Phifer:Handout: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_download_attachments_66086750_RDSPDP-2DHandout-2DFor29AugCall-2Dv2.pdf&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=QiF-05YzARosRvTYd84AB_UYInlydmFcjNmBM5XgySw&m=Or62BeYmZRtfMAuXRqyOjaoanchxiSNJveLu4T8GB4w&s=2X4NvGD3-oKUHrx4p3SIeSP6NvMu9d8aOr0TJ0DWd_U&e=
Alex Deacon:Good Morning....
Lisa Phifer:Poll results: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_download_attachments_66086750_AnnotatedResults-2DPoll-2Dfrom-2D22AugustCall-2Dv2.pdf&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=QiF-05YzARosRvTYd84AB_UYInlydmFcjNmBM5XgySw&m=Or62BeYmZRtfMAuXRqyOjaoanchxiSNJveLu4T8GB4w&s=FZ3D1CEFD2qb29v0r-fzJ_6VCaGlfi2_5BSrK8CJMmQ&e=
stephanie perrin:So are poll results now considered to be rough consensus decisions?
Lisa Phifer:Q2: Reseller must be supported by theRDS, and must be provided for inclusion in the RDS by Registrars
Greg Aaron:Joining late
Lisa Phifer:Yes, Chuck, see page 3
Volker Greimann:I support the statement if amended as suggested by Chuck
Kal Feher:my response appears to have been coded incorrectly. I am in the same camp as Rogey Carney and friends.
Lisa Phifer:Proposed WG Agreement: Reseller must be supported by the RDS, and must be provided for inclusion in the RDS by Registrars
Sara Bockey:Agree with Stephanie, I thought it was agreed that the poll results were just to take a "pulse" of the room and NOT rough consensus.
Volker Greimann:I do not support the language as proposed on page 3
Volker Greimann:Strongly opposed here!
Lisa Phifer:@Kal, let me check coding
Ayden Férdeline:+1 Stephanie and Sarah
Volker Greimann:Chuck, the poll does not denote consensus, it is an indication
Marika Konings:Poll results are intended to measure the support for possible WG agreements - not formal consensus calls.
Lisa Phifer:@Kal, coding does in fact reflect the option you selected for this question
Volker Greimann:the proposal in (5) is acceptable
Kal Feher:@lisa. oh. I'm coloured differently to those responses.
andrew sullivan:There's a deep problem with that kind of ambiguity, since it is way worse to have a data element that does not mean exactly one thing than it is just not to have the data
andrew sullivan:So if the idea is that this is the reseller from the point of view of the registrar, then we should define it
andrew sullivan:i.e. "registrar's reseller" would be fine with me
Lisa Phifer:@Kal, the option you chose was I do not support, thus blue coding - but your comment text does explain what you disagreed with
Volker Greimann:this is problematice
Volker Greimann:YES!
Volker Greimann:Strongly object
Volker Greimann: will dial in
Greg Aaron:Please see my note about curent COnsensus Policy
Lisa Phifer:Proposed WG Agreement (revised): Reseller must be supported by the RDS, and must be provided for inclusion in the RDS by Registrars. Note: There may be a chain of Resellters, to be addressed during definition of this data element.
Lisa Phifer:Voker said Roger's proposal in #5 would be acceptable
Volker Greimann:on the call now
Julie Bisland:volker is on audio now
Lisa Phifer:COmment 5: "Reseller Name must be supported by the RDS, and MAY be provided for inclusion in the RDS byRegistrars."
Sara Bockey:@Marika - then why does Chuck continue to say rough consensus?
Lisa Phifer:All polling to date has been moving us towards rough consensus, but is not formal consensu
Lisa Phifer:That approach has been in our agreed work plan since late 2016
Marika Konings:rought consensus support for the proposed WG agreement - I think he is just using short hand :-)
Greg Shatan:My response was not a vote, it was a well-considered expression of opinion.
stephanie perrin:But since ICANN operates on rough consensus, once you start saying we have rough consensus, you are done. We were using those polls for a rough idea of how we felt on issues....there is no acceptable agreed shorthand for "rough consensus" . Perhaps we need one to be defined.
Lisa Phifer:Proposed WG Agreement (another alternative, based on comment #5): "Reseller Name must be supported by the RDS, and MAY be provided for inclusion in the RDS byRegistrars. Note: There may be a chain of Resllers."
Maxim Alzoba (FAITID):provided if known to the registrar
jonathan matkowsky:I apologize for not being able to participate in this week's poll, but wanted to emphasize if it hasn't been already that Reseller must be supported by the RDS as Whois inaccuracy is often an indicator for malicious registrations and although the registrar is contractually responsible, it is important that people be able to contact the reseller quickly--and that this information be available as registrars might be slower in reaching their reseller
andrew sullivan:It seems to me that the reason we want to do this is in support of something. The support has to do with contacting someone re: the operation of the name in quesstion
andrew sullivan:the registrar's reseller is a good step along the path to contacting the domain operator of that thing
Daniel K. Nanghaka:May makes its optional and MUST is confirming the situation
andrew sullivan:and it is information that the registrar can be expected actually to have (so it will be correct if it is there)
Sara Bockey:Agree with Stephanie. Words matter and polling is not votes. We need to be clear.
andrew sullivan:we need 1. data that we can be sure is correct 2. for a purpose that is legitimate
Daniel K. Nanghaka:To reach consesus then we have to create options for contact and verification
Marika Konings:@Stephanie, Sara, formal consensus designation are outlined in the charter and the WG guidelines. These are not formal consensus calls but an attempt to arrive at rough consensus / agreement on proposed WG agreements which eventually will be put out for a formal consensus call.
Maxim Alzoba (FAITID):and if there are two resellers?
stephanie perrin:This is particularly problematic given the somewhat unpredictable nature of the polls, and the fact that we don't actually get input to the questions. One week we may have a honking big one that requires a lot of work (eg the one adjacent to the JOburg meeting) and the next a two question item.
stephanie perrin:I understand that Marika. But language, as Sara has noted, is important. We need to be very precise on what we have reached agreement. So far, not much.
Lisa Phifer:Please refer to https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_oIxlAw&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=QiF-05YzARosRvTYd84AB_UYInlydmFcjNmBM5XgySw&m=Or62BeYmZRtfMAuXRqyOjaoanchxiSNJveLu4T8GB4w&s=bIpwMQegMLj5R_OFWykdutVYg-sdwWj8E1jIsRBU6lQ&e= for the work plan which documents the approach we are using, including how polls are being used to build rough consensus but formal consensus will not be atttempted until end of phase
Marika Konings:for some of the big polls, like the one after Jo'burg, additional time was made available for WG members to respond. And on various instances further polls have been conducted based on the input to the initial poll and further evolution of proposed WG agreements.
Krishna Seeburn - Kris:Agree with Alan......this does happen....
Marika Konings:Note that all preliminary WG agreements on key concepts are captured here: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_download_attachments_66086747_KeyConceptsDeliberation-2DWorkingDraft-2D22August2017.pdf-3Fversion-3D1-26modificationDate-3D1503633778000-26api-3Dv2&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=QiF-05YzARosRvTYd84AB_UYInlydmFcjNmBM5XgySw&m=Or62BeYmZRtfMAuXRqyOjaoanchxiSNJveLu4T8GB4w&s=SRofNC8_nhM2K3MdlnaMk-B7MaKi2QB-3hniAckI5ng&e=
andrew sullivan:I cannot accept any argument that amounts to, "This legitimate purpose is not to be satisfied because someone's business model depends on hiding their own identity to avoid poaching"
Marika Konings:But if someone has any ideas or suggestions on a better way to get to preliminary agreement on some of these concepts, I am sure that the leadership team is very happy to hear those :-)
andrew sullivan:It is not ICANN's job to produce policy that protects lousy vendors.
Daniel K. Nanghaka:@andrew +1 I agree
andrew sullivan:Any database I can think of could trivially model all these relationships. That's not the problem. The problem is that not everyone involved will have all the information, so you can't be sure you have the right data if the goal is to get the whole chain
Benny Samuelsen / Nordreg AB:So none who see practical problems shall just stay silent?
stephanie perrin:IS this the document you are referring to Lisa? https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_pages_viewpage.action-3FpageId-3D56986784-26preview-3D_56986784_61609526_Possible-2520approach-2520to-2520consensus-2520v13-2520clean-2520-2D-252018-2520Jul-252016.docx&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=QiF-05YzARosRvTYd84AB_UYInlydmFcjNmBM5XgySw&m=Or62BeYmZRtfMAuXRqyOjaoanchxiSNJveLu4T8GB4w&s=WiLu5c1o6_D4IsF7O4QZxpZ0BAQ38t3f7VDuOZQWkjw&e=
Greg Shatan:Not what I said.
Maxim Alzoba (FAITID):I think the party most educated about resellers - is RrSG - we might request formal responce from them
stephanie perrin:I don't actually see any reference to the use of Doodle polls....
Benny Samuelsen / Nordreg AB:Not to you Greg but Andrews comment about lousy vendors
Lisa Phifer:If you think Registrars should be requjired to identify Resellers in RDS (Registrars MUST provide) put green check
Maxim Alzoba (FAITID):we need to add "if known"
Lisa Phifer:If you disagree - you think that Registrars MAY provide - put red X
Greg Shatan:To be clear, concerns about implementation should be surfaced, but don't justify reversing the top-line policy concept. Not trying to quash anyone's right to harp on minutiae.
Ayden Férdeline:
andrew sullivan:@Benny: no. I am saying that if someone doesn't want to appear in the RDS even though the information is needed for a legit purpose, then the argument that they don't want that for business reasons is not a good reason to permit the exclusion
Greg Shatan:Thanks for clarifying Benny.
jonathan matkowsky:Can you please count the poll results?
Maxim Alzoba (FAITID):it is not a poll
Lisa Phifer:Suggest we re-poll on two variants - MUST and MAY - including (if applicable) and note that REsellers may be a chain.
Maxim Alzoba (FAITID):offline members can not use it
jonathan matkowsky:Sems like 11 or 12 in favour of must to 2 or 3 in favour of not
jonathan matkowsky:doesn't seem like a split
Volker Greimann:and the poll should differentiate between GNSO constituencies.
Lisa Phifer:show of hands indicated perhaps 5 red Xs and 8 green checks (but some people cleared their checks or Xs)
Lisa Phifer:Show of hands is not a poll, just taking the sense of the room
Volker Greimann:if the polls are decised by sheer numbers, I will go out tomorrow and sign our entire staff up for the group
Maxim Alzoba (FAITID):@jonathan, it was more (using scroll)
andrew sullivan:I don't believe the polls are decided by sheer numbers, at least as far as I can tell. If they are, I'll cheerfully quit, since this would be a waste of time :)
Volker Greimann:@andrew: I hope so too
Lisa Phifer:@Volker, as agreed and noted in the introduction to every poll, poll responses are not assumed to reflect the views of any organization or company you are affiliated with
jonathan matkowsky:@maxim thanks, i thought i did but doesn't seem to matter what the results were
Maxim Alzoba (FAITID):@Volker, please request opinion of RrSG for our PDP (about this question )
Marika Konings:@Andrew - you are correct. The leadership does evaluate affiliation of respondents and factors that into its assessment.
Volker Greimann:right, but then they cannot be a source to determine consensus
Volker Greimann:we do not want a result that would not be able to pass the council after all
Lisa Phifer:@Volker, you are correct that poll results do not indicate formal consensus - the hope is they move us gradually, iteratively, towards consensus. But we cannot make progress if we dinsist upon formal consensus from the start of our key concepts
Greg Shatan:Volker, why do you think a result achieved by consensus (however determined) from a WG would not be able to pass the council?
Maxim Alzoba (FAITID):what is the value in knwoing that the domain was registered 20 years ago and deleted 19 years ago?
Lisa Phifer:Chuck is now on page 7 - see Proposed WG Agreement given there for discussion
jonathan matkowsky:fixing it now
Lisa Phifer:Proposed WG Agreement (based on poll results, including comments)The Original Registration Date (see footnote below) must be supported for inclusion in the RDS.
jonathan matkowsky:you can go on to the next person for now please
Lisa Phifer:Footnote: This agreement received both strong support and noteworthy opposition in 22 August poll. Further deliberation to address concerns raised, including this data element's definition, starting from the working definition given on page 57 of the EWG Report: This is different than the creation date since the creation date picks up the latest time that the domain name was registered; it is possible that the domain name was previously registered and subsequently deleted multiple times. The Original Registration Date denotes the first date that the domain name was ever registered.
Maxim Alzoba (FAITID):then it is not original
Lisa Phifer:Alternative proposal: The most recent prior registration date (if the domain has been re-registered by anyone, not necessarily the current registrant) must be supported for inclusion in the RDS.
andrew sullivan:That's already there: created_on is part of the EPP specification
andrew sullivan:(maybe it's spelled createDate or something like that -- I forget)
Lisa Phifer:@Andrew, not creation of the current registarion, but the prior (if there was one) - I think - is what he's suggesting
Tim OBrien:+1 jonathan
andrew sullivan:I think that may not be what he's saying, but I get it
Maxim Alzoba (FAITID):Creation Date: is in current WHOIS
stephanie perrin:+1 Andrew
Benny Samuelsen / Nordreg AB:+1 Andrew
steve metalitz:@Andrew could you explain why some registries can't provide this data?
stephanie perrin:Current WHOIS is the problem we are trying to solve, let us remember that.
Maxim Alzoba (FAITID):it could be text "not known"
Scott Hollenbeck (Verisign):@Steve : they may just not have it. Think operators transfers, for example
andrew sullivan:@Stephanie: the most obvious is org
andrew sullivan:org is now operated by PIR
Lisa Phifer:@Alan, working definition given on page 57 of the EWG Report: This is different than the creation date since the creation date picks up the latest time that the domain name was registered; it is possible that the domain name was previously registered and subsequently deleted multiple times. The Original Registration Date denotes the first date that the domain name was ever registered.
andrew sullivan:it used to be operated by Verisgn
andrew sullivan:Verisign
jonathan matkowsky:The first creation date is already required though
andrew sullivan:I can tell you for sure (because I was on the pointy end of the transition) that PIR does not have and cannot get the original creation date of any domain in the org registry prior to that transition
andrew sullivan:the first creation date is impossible to get
Lisa Phifer:Often obtained from DomainTools today, used to determine longevity of a domain name, as I understood it during EWG discussion
andrew sullivan:the creation date of the domain object is required
Greg Shatan:Why did EWG recommend this?
andrew sullivan:The DomainTools date is often bad data
andrew sullivan:they literally don't know that all the time, and they just lie to you sometimes
Lisa Phifer:I believe this WG already agreed to include Creation Date in the Min Public Data Set. This is different
andrew sullivan:@GregS because it's valuable to know that example.com that you're looking at is not the first case of example.com that existed
Maxim Alzoba (FAITID):at lest this idea is behind ROIDs, which make registrations unique
steve metalitz:@Andrew, thanks. So is it standard that when operation of a registry is transferred, past registratoin data is not transferred? Or is the example limitd to what Verisign does (or did)?
andrew sullivan:it'd be genuinely valuable if it were available, but it isn't normally
andrew sullivan:or everywhere, rather
andrew sullivan:@Steve: I don't know about other registries, but ones that I have built permitted deletion of domain objects
Lisa Phifer:WG Agreement 27: Today's gTLD WHOIS registration data elements classified as "thin"
are sufficient at this time, to be referred to within WG Agreements hereafter as the "Minimum Public Data Set."
andrew sullivan:the objects literally disappear from the registry
Lisa Phifer:The list agreed includes Create Date
andrew sullivan:there might be some downstream system that has historical data about registry states, but the registry itself does not
Alan Greenberg:I can see that the long-term history of a name is valuable. But when it was originally registered without the history seems far less valuable.
andrew sullivan:that's what a registry is like
andrew sullivan:it's the current state of registration, not the history of all registrations
stephanie perrin:Lisa, It looks like this conversation is an example of the revisiting we discussed....
stephanie perrin:Valuable to whom is the question.
andrew sullivan:Please note that I am not saying it's not valuable to have this data. I'm saying we literally do not have it reliably, and unreliable data is worse than nothing
Tim OBrien:good point jonathan on IP issues
Lisa Phifer:working definition given on page 57 of the EWG Report: This is different than the creation date since the creation date picks up the latest time that the domain name was registered; it is possible that the domain name was previously registered and subsequently deleted multiple times. The Original Registration Date denotes the first date that the domain name was ever registered.
Volker Greimann:This is a valid concern, jhowever it becomes worthless for that purpose once registrations change hands.
stephanie perrin:The fact that this info is valuable to a third party is not a sufficient reason for ICANN as data controller to insist that it be collected. Or disclosed
steve metalitz:@Andrew, thanks, got it. So does that argue for this data element to be supported but optional (since in some cases it can't be provided).
andrew sullivan:The "onlt when available" case is a terrible formulation because it'll give both false positives and false negatives
Greg Shatan:RDS exists for the use of the users, not the data controller.
andrew sullivan:For instance, mitre.org has a creation date in 1985. I don't know whether that's actually true: it could well be that it was created _before_ that when the DNS was first invented, but nobody tracked it sooner than 1985
stephanie perrin:Spoken like a third party user, Greg. I am sure it is a valid concern. But the registrants do have rights.
jonathan matkowsky:I agree that no data is better than bad data but there must be a way to require accurate data of when a domain was most recently registered on a going forward basis
andrew sullivan:and we know for sure that there are domains that have been deleted and recreated since their original date but that are very valuable
Greg Shatan:This has nothing to do with registrant rights.
andrew sullivan:(hotmail.com is an example of that)
Fabricio Vayra:@Stephanie -- What does an original creation date say/reveal about anyone one person? Meaning, how is it personally identifiable -- fail to see the connection.
andrew sullivan:such a name will have bad data about it, even though it should have the original date (which is probably now lost)
andrew sullivan:and so on
Greg Shatan:In any event, someone has to speak for the users (I think even the term third party user is inappropriate).
jonathan matkowsky:what do you need help with that we are taking a vote on?
Lisa Phifer:To be clear: The EWG recommendations required the field to be supported by the RDS, but optional to collect because it would not always be known
Maxim Alzoba (FAITID):chain of ROIDs would have the info about the history, but they are not long in the field
jonathan matkowsky:volunteers for what?
stephanie perrin:"Personal information" does not mean "personal characteristics" Fab, as you know.
jonathan matkowsky:i couldn't hear
Lisa Phifer:Request is for volunteers to assist with proposing an alternative WG agreement to balance points of view expressed
andrew sullivan:@Lisa: my point is that it's 2d order ignorance: it's not just that you might not have it, but also that you might have the wrong one or you might not know that you are missing data you ought to have
andrew sullivan:that's what's wrong with this element
Fabricio Vayra:@Stephanie - Still not seeing the connection? Where does the creation date for a domain relate in any way to PII or relate to an individuals data?
Lisa Phifer:@Andrew, I get it - just sharing past rationale
stephanie perrin:If I originally created my domain names on a certain date, is that not my personal data? If not, what character does that data have?
jonathan matkowsky:I put up my hand
Greg Shatan:The data relates to the first time it was created by anyone, not by the current registrant.
Fabricio Vayra:@Stephanie - domain X created Y date = nothing about registrant who originally registered.
stephanie perrin:Particularly when I might wish to argue for my intellectual property rights in respect of those domain names...
Greg Shatan:In any event, I would not characterize any registration date as personal data.
Greg Shatan:No one is preventing anyone from arguing for their intellectual property rights. Indeed, this would facilitate arguing for IP rights, regardless of which side of the argument one is on.
Fabricio Vayra:@Stephanie ??? Still not seeing the connection or your arguement that a creation date without more has anything to do with PII etc.
Tapani Tarvainen:@Fabricio: regardless of who originally registered it'd be their personal data, no?
Lisa Phifer:Possible alternative WG Agreement (based on poll results, including comments)A Registrar Abuse Contact must be supported for inclusion in the RDS, and must be provided by Registrars. Registrars should have a choice of abuse contact method(s) they support.
Fabricio Vayra:+! Greg. So, Stephanie, you just supported the inclusion for the benefit of the original registrant
Lisa Phifer:See page 9
Maxim Alzoba (FAITID):abuse contact and phone is in the current CL&D policy
stephanie perrin:The better view, Greg, I would argue, is that if a domain name relates to/is registered by an individual, the data related to that is personal. Stuff like nameservers is hard to argue but not original creation data.
stephanie perrin:date
stephanie perrin:Actuallly no Fab, please don't put words in my mouth.
Fabricio Vayra:@Stephanie - You keep coming to the conslucion that a creation date says something about a person. How do you get there? There is no connection.
Lisa Phifer:For discussion now: Page 9: Possible alternative WG Agreement (based on poll results, including comments)A Registrar Abuse Contact must be supported for inclusion in the RDS, and must be provided by Registrars. Registrars should have a choice of abuse contact method(s) they support.
Maxim Alzoba (FAITID):currently e-mail and phone has to be there https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources_pages_rdds-2Dlabeling-2Dpolicy-2D2017-2D02-2D01-2Den&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=QiF-05YzARosRvTYd84AB_UYInlydmFcjNmBM5XgySw&m=Or62BeYmZRtfMAuXRqyOjaoanchxiSNJveLu4T8GB4w&s=iw-DkpVBPMeg_KnGAVYCZgBi_JGgEq8dZjoUPUURnZs&e=
Tapani Tarvainen:The date a person does something is data about that person. I don't see how that's even questionable.
Lisa Phifer:@Maxim, yes, the statements polled on reflect the current RAA requirements
Tim Chen:a date is not personal
Tim Chen:totally agree with fabricio on this
Tim Chen:if it s 70 degrees outside at the time you make a decision, is that personal? how far are we taking these arguments?
Tapani Tarvainen:Of course a date is personal it if tells something about a person, like when they did something,
steve metalitz:@Tapani so if a DN was originally registered on 1/1/2000 how is that identifiable to a natural person? At most it tells me that if the registrant was a natrural person he or she had been born by that date.
Maxim Alzoba (FAITID):365 days per year and more that hindred million registrations ... correlation with particular persons are quite low
Alan Greenberg:@Tapani, the date that a person wins an olymppic gold medal is a matter of public record and cannot be considered their personal data. Since a domain name's exitance (but not who registered it) is a matter of public record, the date is not linked to the person.
Fabricio Vayra:@Tapani How does a date in history, without more, say anything about anyone? e.g., Tapani.com was registered in 1/1999. What does that tell you about anyone -- nothing.
jonathan matkowsky:I agree with Volker on this
Tapani Tarvainen:@Alan Huh? Of course an olympic medal winning date is personal data, even if it is a matter of public record. Its being public does have consequences, but it doesn't mean it's not personal.
Greg Shatan:Well, I'm glad that we've establish that personal data can be public or made public.
jonathan matkowsky:If a domain is masked with privacy and is compromised hosting by a different provider than the registrar, the registrar abuse contact should help to reach the registrant
Greg Mounier:@Volker: phone numbers are indeed very useful for public safety agencies to urgently contact a registrar or registrant. In cases of emergency investigators will rely on phone numbers found in the RDS.
Greg Shatan:Defining abuse is way beyond the remit of the database.
Greg Shatan:or even this WG.
Alex Deacon:We shouldn't artificially limit what kinds of abuse Registrars and Registries accept or not.
jonathan matkowsky:+1 Alex
Greg Shatan:+1 Alex.
stephanie perrin:Alan, a date that pertains to an individual (let us take the date of a surgery, rather than something like a gold medal) appears in a published record absent the identifier that links it to the individual (eg the surgeon or hospital, recognizing the well known rules of stats and deidentification, we used to use the number 4) that does not mean that the date loses its character as personal data.
Tapani Tarvainen:@Fabricio date with nothing more would of course say anything about anyone, but as long as the date is tied to something that can be connected to a person situation changes. Even if sometimes the original registrant is untraceable, there surely are cases where he or she is known.
jonathan matkowsky:We could still support though some kind of educational disclaimer that registrar abuse contacts should not be abused
Fabricio Vayra:+1 Alex and Greg. The point here is where the contact for abuse should be avilable in the first instance, right?
Greg Shatan:Sounds like an FAQ issue, not an RDS issue.
Fabricio Vayra:+1 Greg
jonathan matkowsky:+1 Greg
Maxim Alzoba (FAITID):Registries & PSWG created Security Framework - which describes typical issues/ways to resolve
Maxim Alzoba (FAITID):about abuse
Maxim Alzoba (FAITID):P.s: it was created with participation of Registrars too
jonathan matkowsky:A hyperlink to an FAQ would be useful
Maxim Alzoba (FAITID):https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_download_attachments_54693403_Security-2520Framework-2520draft-2520v8.pdf-3Fversion-3D1-26modificationDate-3D1496856148000-26api-3Dv2&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=QiF-05YzARosRvTYd84AB_UYInlydmFcjNmBM5XgySw&m=Or62BeYmZRtfMAuXRqyOjaoanchxiSNJveLu4T8GB4w&s=5VBAWis_7Q-6GCdNwVuYkMx_7IaYVGQrhsjChts7TD4&e=
Lisa Phifer:@Steve: WG Agreement #26: RDS policy must include a definition for every gTLD registration data element including both a semantic definition and (by reference to appropriate standards) a syntax definition.
jonathan matkowsky:Steve raises a great point that the data elements should be defined including registrar abuse contact - I also agree that preferred method of contact in addition to phone and email should be OPEN standard
Lisa Phifer:WG Agreement #31: At least one element enabling contact must be based on an open standard and not a proprietary communication method.
Maxim Alzoba (FAITID):if we add too strange things - we might see one day "only abuse reports sent by black pigeons are valid"
jonathan matkowsky:What about a privacy abuse contact?
jonathan matkowsky:It is usually the registrar but may not be the same point of contact
Lisa Phifer:See Greg's comment 7: 1) A very recent Consensus Policy (effective 1 August 2017) just stated that Registrar AbuseContact Email and Registrar Abuse Contact Phone MUST be PUBLISHED (and must therefore beprovided by registrars). See https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources_pages_rdds-2Dlabeling-2Dpolicy-2D2017-2D02-2D01-2Den&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=QiF-05YzARosRvTYd84AB_UYInlydmFcjNmBM5XgySw&m=Or62BeYmZRtfMAuXRqyOjaoanchxiSNJveLu4T8GB4w&s=iw-DkpVBPMeg_KnGAVYCZgBi_JGgEq8dZjoUPUURnZs&e= #1 2) I therefore suggest this wording: "The Registrar Abuse Contact Email and RegistrarAbuse Contact Phone must be supported for inclusion in the RDS, must be provided byRegistrars, and must be published."
Marc Anderson:technically we are talking about registrar abuse contact info, not domain abuse contact info
Fabricio Vayra:+1 Greg A
Maxim Alzoba (FAITID):cL&D require
jonathan matkowsky:Anyone here support including a privacy abuse point of contact?
Lisa Phifer:See Greg's comment 7: 1) A very recent Consensus Policy (effective 1 August 2017) just stated that Registrar AbuseContact Email and Registrar Abuse Contact Phone MUST be PUBLISHED (and must therefore beprovided by registrars). See https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources_pages_rdds-2Dlabeling-2Dpolicy-2D2017-2D02-2D01-2Den&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=QiF-05YzARosRvTYd84AB_UYInlydmFcjNmBM5XgySw&m=Or62BeYmZRtfMAuXRqyOjaoanchxiSNJveLu4T8GB4w&s=iw-DkpVBPMeg_KnGAVYCZgBi_JGgEq8dZjoUPUURnZs&e= #1 2) I therefore suggest this wording: "The Registrar Abuse Contact Email and RegistrarAbuse Contact Phone must be supported for inclusion in the RDS, must be provided byRegistrars, and must be published."
Maxim Alzoba (FAITID):and phone too
Lisa Phifer:Possible alternative proposed WG agreement: Per recently approved consensus policy (link), The Registrar Abuse Contact Email and RegistrarAbuse Contact Phone must be supported for inclusion in the RDS, must be provided byRegistrars
Maxim Alzoba (FAITID):it is questionable if Registrars shoudl reply to SPAM e-mails
andrew sullivan:What is this "RDS landing page" of which people speak? I still don't think we can design user interfaces.
jonathan matkowsky:Provide info the way we provide info on domain status - a link to ICANN's website with more info
jonathan matkowsky:It doesn't have to be a "disclaimer" per se
andrew sullivan:Unfortunately I have to drop off
andrew sullivan:bye all
jonathan matkowsky:bye andrew
Nathalie Coupet:bye
Volker Greimann:fully agreed, Greg. Not in the output
Volker Greimann:but we may have hover-over or links
Greg Shatan:A separate FAQ or explanatory text may be good, however executed. I suggest a talking paper-clip.
Krishna Seeburn - Kris:@ volker it makes sense... i understand where you getting to ...
Lisa Phifer:Possible alternative proposed WG agreement: Per recently approved consensus policy (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources_pages_rdds-2Dlabeling-2Dpolicy-2D2017-2D02-2D01-2Den&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=QiF-05YzARosRvTYd84AB_UYInlydmFcjNmBM5XgySw&m=Or62BeYmZRtfMAuXRqyOjaoanchxiSNJveLu4T8GB4w&s=iw-DkpVBPMeg_KnGAVYCZgBi_JGgEq8dZjoUPUURnZs&e= ), The Registrar Abuse Contact Email and RegistrarAbuse Contact Phone must be supported for inclusion in the RDS, must be provided byRegistrars
Lisa Phifer:Greeen check if you support this, red X if not
Alan Greenberg:I need to leave now. Bye all.
Nathalie Coupet:bye
Lisa Phifer:@Jonathan re: privacy abuse point of contact, we will make note to circle back to this additional data element suggestion with other new data element suggestions
stephanie perrin:Thanks for that clarification Mark
Maxim Alzoba (FAITID):we have two kinds of WHOIS - Registrar & Registry and they re not the sme
Lisa Phifer:Raise hand if you opposed requireing a Registrar email abuse contact
jonathan matkowsky:@Lisa thank you very much
Greg Shatan:@Stephanie, I think Jonathan M. answered the mode of contact question earlier in the meeting, w.r.t. scaling threat management, etc.
Alex Deacon:@volker +1. minimum requirements are important.
stephanie perrin:Thanks, I am v happy with that response, let me make that clear. I was just checking....
Greg Shatan:I support the "Holy Trinity": email, phone and physical address.
Krishna Seeburn - Kris:+1 greg :)
Fabricio Vayra:+1 Greg
Maxim Alzoba (FAITID):bye all
Nathalie Coupet:bye all
Daniel K. Nanghaka:Bye All
Fabricio Vayra:thanks and bye to all
Sara Bockey:thanks all!
Krishna Seeburn - Kris:bye all...
Benjamin Akinmoyeje (Nigeria):Bye
David Cake 2:be all
Lisa Phifer:Action: All WG members are asked to review today's handout to prep for next week's call: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_download_attachments_66086750_RDSPDP-2DHandout-2DFor29AugCall-2Dv2.pdf&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=QiF-05YzARosRvTYd84AB_UYInlydmFcjNmBM5XgySw&m=Or62BeYmZRtfMAuXRqyOjaoanchxiSNJveLu4T8GB4w&s=2X4NvGD3-oKUHrx4p3SIeSP6NvMu9d8aOr0TJ0DWd_U&e=
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170829/ae6c77d2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Attendance RDS PDP 29 August.pdf
Type: application/pdf
Size: 337948 bytes
Desc: Attendance RDS PDP 29 August.pdf
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170829/ae6c77d2/AttendanceRDSPDP29August-0001.pdf>
More information about the gnso-rds-pdp-wg
mailing list