[gnso-rds-pdp-wg] Recordings, Attendance & AC Chat from Next-Gen RDS PDP Working group call on Tuesday, 21 November 2017 17:00 UTC
Julie Bisland
julie.bisland at icann.org
Tue Nov 21 20:24:19 UTC 2017
Dear All,
Please find the attendance of the call attached to this email, and the Adobe Connect chat, MP3 & Adobe Connect recording below for the Next-Gen RDS PDP Working group call held on Tuesday, 21 November 2017 at 17:00 UTC.
MP3: http://audio.icann.org/gnso/gnso-nextgen-rds-pdp-21nov17-en.mp3
AC recording: https://participate.icann.org/p7011hupgmm/<https://participate.icann.org/p7011hupgmm/?OWASP_CSRFTOKEN=c5dc117acd7d7b4d65d028e4b8b4cd2806a0dcdefbc08737427d20d0f97a6a85>
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/LAByB
Thank you.
Kind regards,
Julie
---------------
AC Chat Next-Gen RDS PDP WG Tuesday, 21 November 2017
Julie Bisland:Welcome to the GNSO Next-Gen RDS PDP Working Group teleconference on Tuesday, 21 November 2017 at 17:00 UTC.
Julie Bisland:Agenda wiki page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_LAByB&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=QiF-05YzARosRvTYd84AB_UYInlydmFcjNmBM5XgySw&m=QX-6Z9y15hFk2klyWFcxqYFgtCC1uNnRJPIrDPsB9JQ&s=oJW-jRv-hFWaW4U1BFDK2pPv8MiiB6ADAyTNS-VmgzU&e=
Susan Kawaguchi:Good morning all!
Susan Kawaguchi:or evening!
Nathalie Coupet:good morning
Sam Lanfranco:Good midday!
Lisa Phifer:The handout to be displayed during today's call: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_download_attachments_74580012_Handout-2D21Nov-2DRDSWGCall-2Dv3.pdf&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=QiF-05YzARosRvTYd84AB_UYInlydmFcjNmBM5XgySw&m=QX-6Z9y15hFk2klyWFcxqYFgtCC1uNnRJPIrDPsB9JQ&s=K38c_3AFX--x7qW__66-k2y8NiefwgKIwud-je8z5_A&e=
Michael Hammer:Greetings.
Maxim Alzoba (FAITID):Hello All
Alan Woods (Donuts):Apologies - I am stuck on audio only - (no mic today)
Stephanie Perrin:As mentioned earlier, I did really nothing for this project so someone else would be better
Lisa Phifer:We are on agenda item 2 - slide 3
Greg Shatan:I will help out...
Lisa Phifer:We are now on slide 4
Lisa Phifer:We are now on slide 5 - presentation by DT1 of Technical Issue Resolution as a possible purpose for collecting registration data
Juan Manuel Rojas (NPOC):Good afternoon..
andrew sullivan:There is
andrew sullivan:The most obvious case is where you can spot a DNS mismatch
Lisa Phifer:We are on slide 7, addressing the question "Are there any clarifications necessary to understand this purpose before we can begin deliberating on this purpose?"
andrew sullivan:That is, you get (e.g.) a mail bounce because the name doesn't exist, and you look in whois and see the domain is on Hold, then you know that there's no actual technical problem to solve
andrew sullivan:because the name shouldn't resolve. Problem answered
andrew sullivan:(imagine you're working a help desk, for instance)
Stephanie Perrin:Faintly
Stephanie Perrin:Yes better
Rod Rasmussen:That was NOT the assignment Volker.
David Cale:Stephanie just noted that I am signed in today as David Cale, not David Cake. Ooops.
Rod Rasmussen:Make that Kale, and you're very healthy
Julie Bisland:I just updated you name to show correctly, David. Thank you
Alan Greenberg:Also, since hosting providers are nested, it is not clear from the IP address exactly who the hosting provider is.
Volker Greimann:+1 for James
Volker Greimann:the use case is too broad
Krishna Seeburn - Kris:+1 james
Stephanie Perrin:+ 1 James.
Sara Bockey:Agree with James
David Cake:Thank you Julie.
Alan Woods (Donuts):+1 Jim
Beth Bacon:agree, Jim
Stephanie Perrin:Thank you for raising this. The facts of this matter are not lost on the DPAS either. We do not publish our banking data (name address phone number email) and doubtless it would be useful for someone.
Alex Deacon:+1 Andrew
Rod Rasmussen:Thank you Andrew!
Michael Hammer:+1 Andrew
Greg Aaron:Yes, the last 30 years were not just a dream....
Fabricio Vayra:+1 Andrew. And this is why the current "Revised ICANN Procedure For Handling WHOIS Conflicts with Privacy Law" constantly references "Keeping in the mind the anticipated impact on the operational stability, reliability, security, or global interoperability of the Internet's unique identifier systems" when discussing changes to WHOIS.
Maxim Alzoba (FAITID):not all things ICANN does are fine
Maxim Alzoba (FAITID):and DNS does not need to have all info we currently collect to function
Krishna Seeburn - Kris:i still think we need to find the middle ground and if we cannot have icann do this thien maybe the registrar can and icann kepp those data inhouse and covered
Tim Chen:@maxim data minimization is not an ICANN remit
Lisa Phifer:Note that the task was to define the purpose not all use cases associated with the purpose. It is useful to identify when you have sufficiently different use cases that they are different purposes - that allows us to deliberate on each purpose separately
Julie Bisland:I'll priv chat David if you want to move on
Krishna Seeburn - Kris:seems lke he is speaking but no sound
Fabricio Vayra:+1 Tim. And data minimization also doesn't = less data, but no more data than necessary to fulfill the purpose.
Rod Rasmussen:To put 1+1 together - Alan and Andrew - ICANN is responsible for SSR or the Internet, the responsibilty for the Internet is distributed to many different organizations and individuals, these things all interoperate to make the Internet actually "work", technical issues in one space can affect others, someone needs to be contacted in order to solve many of these issues to keep the Internet working, ICANN is charged with managing the distribution of these resources, thus it comes back to ICANN to ensure that issues can be resolved via contacts associated with the domains it manages the distribution of, thus RDS.
Maxim Alzoba (FAITID):we should not forget that Internet without live Registries and Registrars is not going to be a good place (it might happen if we try to collect too much and fined to the bankruptcy for that... GDPR e.t.c.)
David Cake:I can't speak, so I will try to make my point in chat.
andrew sullivan:I don't actually think ICANN is responsible for _distributing_ the resources. They're (we're) just responsbile for getting that distribution started
Stephanie Perrin:Compliance with law is part of ICANN's remit. Data minimization is part of compliance with law.
Michael Hammer:Is it really a clean slate?
Greg Shatan:It would be nice to see ideas about how to do things better.
Maxim Alzoba (FAITID):@Stephanie , I am not sure ICANN see it the same way
andrew sullivan:Which is again a reason that some of this data needs to be available and how the use cases must have to be handled
andrew sullivan:I don't believe that it is in ICANN's or this PDP's remit to change the fundamentally distributed nature of the databases.
Greg Shatan:I'm not sure about that "clean slate" thing. Ignoring history has not generally proved to be a good planning practice.
Stephanie Perrin:Tiered access is a way to do things better, with accreditation of those who access personal data.
David Cake:Point was simply that there are technical problems that arise directly from entries in the DNS eg SPF - so surely they should qualify under this purpose, even if issues related to eg hosting provider do not?
andrew sullivan:If this use case is not the basic, fundamental use case for the RDS, then I think we have completely lost our collective mind.
Greg Shatan:security, stability, resiliency, interoperability and trust of the DNS and the Internet are directly within ICANN's remit.
Lisa Phifer:@GregS, this WG is tasked with defining requirements for RDS, no matter whether they are addressed by WHOIS or a new RDS - but focusing on requirements in Phase 1
Maxim Alzoba (FAITID):agree on tiered access, it has it's challenges but might be better then the current idea
Volker Greimann:content ids not DNS tjhough
Alan Greenberg:It is a clean slate only to the extent that theere is no justification for doing something.
Dick Leaning:The world has changed, in fact the world has changed since this working group started
andrew sullivan:I think that David C's point is an excellent example of the very distributed nature I was talking about. I think that's quite right
David Cake:Also existence of DNS specific issues that may prevent email working correctly may be a justification for other contact methods to exist.
Dick Leaning:many many months ago
Greg Shatan:It would be nice to build a better mouse trap. I would not consider learning to live with more mice to be a viable solution....
Rod Rasmussen:@Andrew - and you can't blame Thanksgiving tryptophan for the loss of cognitive faculties yet!
Lisa Phifer:We are on slide 7 - list of data elements in DT1's defiinition
Maxim Alzoba (FAITID):for identification of issues Registrant ROID is enough , and more deep info should be keept separately (and opened only under special procedures and not to all parties)
Lisa Phifer:@Maxim, we are not deliberating on how to access data right now - we are focusing on whether the purpose is legitimate for collecting that data. How to access comes later.
andrew sullivan:I'm in Canada: the tryptophan happened in October (though I am a veg, so didn't have any bird anyway) ;-)
Maxim Alzoba (FAITID):https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources_pages_epp-2Dstatus-2Dcodes-2D2014-2D06-2D16-2Den&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=QiF-05YzARosRvTYd84AB_UYInlydmFcjNmBM5XgySw&m=QX-6Z9y15hFk2klyWFcxqYFgtCC1uNnRJPIrDPsB9JQ&s=Lvuu2EdaeLVX51WITl-eK6RCxNXJWvBZXAanzjrx-4k&e=
Maxim Alzoba (FAITID):more info on Statuses
Maxim Alzoba (FAITID):@Lisa, collection rmight require different procedures than we use now
Rod Rasmussen:@Andrew - obviously the reason for your clear-headed thinking!
Maxim Alzoba (FAITID):even storage in separate location (like THIN whois model)
Lisa Phifer:@Maxim, again - how data is collected depends on agreeing what the data is - we are still deliberation on what data is needed and should be collected
Maxim Alzoba (FAITID):@Lisa, we also need to ask collected by whom and stored where
Stephanie Perrin:Actually Lisa, I thought we had established that there were not purposes for collection??? One of the problems I keep raising.....it may be legitimate to release data for academic research, but that is certainly not the reason we collect it.
Greg Shatan:I don't think that's at all certain, Stephanie.
Lisa Phifer:@Stephanie, we are going through purposes one by one to ask and answer that question for each individual purpose that's been proposed
Stephanie Perrin:This process, while supposedly following an incremental approach, is fundamentally backwards and leads us into all kinds of imprecision. Not surprising given the history of WHOIS, but not acceptable.
Fabricio Vayra:@Stephanie - I don't agree. If we are going to start with clean slate, we need to know what we are drafting a purpose statement to accomplish. And to know that, we need to know these scenarios
Krishna Seeburn - Kris:+1 for separating
Stephanie Perrin:then let us be explicit and honest Fab. IF the goal here is to craft a purpose statement that is broad enough to legitimize all the current disclosures in WHOIS, then say so and we can have a reasonable discussion.
Stephanie Perrin:ICANN's remit is limited. It does not include law enforcement for the Internet, despite the continued support of the GAC for that approach.
Maxim Alzoba (FAITID):+1 for separating , on tech level we might not need to know the person ...to inform or to find patterns ROID is enough
Fabricio Vayra:@Stephanie - The remit includes the operational stability, reliability, security, or global interoperability of the Internet's unique identifier systems, which we've heard over and over again -- on this call too -- that necessitates contact details at a minimum
Stephanie Perrin:TEchnical contacts sure. I don't think anyone is fighting that.
Greg Shatan:The task here was first to identify current purposes and then to discuss them. Is the goal to legitimize, delegitimization or to analyze? I hope it's the third. It would hardly be surprising if most purposes were found to be legitimate, since illegitimate purposes have been weeded out over time.
Krishna Seeburn - Kris:both sides are right....and separation is useful and in ensuring the technical and data subjects etc., are well within law purview....
Maxim Alzoba (FAITID):@Fabricio, until things go south (bad things happened) the person does not need to be known
Krishna Seeburn - Kris:we need a running system and see how we break them
Greg Aaron:What are domains for? They make services work; those services are enabled by and bound to the domain name. For example, web sites reside at a domain name; that's how people find it and identify it. Email originates from and goes to somewhere: addresses at domains.
Stephanie Perrin:Services get us straight into content, which is outside ICANN's remit.
Lisa Phifer:We are now on slide 8, considering criteria and whether Technical Issue Resolution as defined by DT1 is a legitimate purpose?
Michael Hammer:So DNS and RDS/Whois stand alone iwth no relation to anything else?
Maxim Alzoba (FAITID):@Greg, domains just connect Istrings of chars to IP addresses servers and other computers need(simple version )
Greg Aaron:Maxim, you're arguing hat we don;t need domain names, and that IP addresses are sufficiient Which ignores why domain names exist in the first place.
Michael Hammer:What if the email was accepted by the host in the MX record but never reached the intended recipient? Remember that SMTP is store and forward. There may be multiple hops.
Maxim Alzoba (FAITID):@Greg, I am not saying that ... servers do not need, humans need domain names (sometimes, when not using apps on softphones)
andrew sullivan:I'm sorry, but virtually every service on the Internet is heavily dependent on DNS names and not IPs to work
Greg Aaron:That's the point... humans use domain names, and the technical systems do as well.
Krishna Seeburn - Kris:i think most of us understand that the DNS resolves names to IP
andrew sullivan:Dyn wouldn't even have a business if it weren't for people using DNS as an infrastructure control mechanism
andrew sullivan:the "facing humans" part of the DNS is a rump problem
Fabricio Vayra:From the White Paper (establishing ICANN): "... we anticipate that the policies established by the new corporation would provide that following information would be included in all registry databases and available to anyone with access to the Internet ... any other information determined by the new corporation to be reasonably necessary to resolve disputes between domain name registrants and trademark holders expeditiously."
Greg Shatan:@Jim, those sound like security, stability and trust problems to me....
Fabricio Vayra:That's just one of many examples ....
James Galvin (Afilias):@andrew - that sounds right. so the text we're proposing "incidents related to the resolution of the domain"?
Maxim Alzoba (FAITID):@Fabricio, expeditiously is not defined, so slight change of dates might stay withing the same borders
Greg Shatan:We are not limited to "resolution" related issues.
James Galvin (Afilias):@greg - the quesiton is what is in the remit of ICANN?
Lisa Phifer:@Jim, are you saying: ake a distinction between issues with domain name resolution for services associated with the TLD and and issues with the services themselves
Maxim Alzoba (FAITID):+1 ... functioning / fixing/ investigation of issues are different things from the operational perspective
Michael Hammer:I just keep on thinking "Be careful what you ask for, you might just get it."
James Galvin (Afilias):@lisa - yes
Tim Chen:+1 michael
Fabricio Vayra:@James - Pls read the green and white papers and the text/concept that has followed since re: whois
Maxim Alzoba (FAITID):THIN whois?
Michael Hammer:hi Tim, Long time no see.
Rod Rasmussen:I am trying to raise my hand but the system isn't letting me.
Lisa Phifer:@Rod, your hand is up in AC
Michael Hammer:Would looking up the domain help ,Rod?
Maxim Alzoba (FAITID):even given the lack of registrant info in THIN registries those TLDs are still compliant with UDRP e.t.c
Rod Rasmussen:See it now - very odd performance today on my Adobe Connect. Have to check for a virus. ;-)
James Galvin (Afilias):@fabricio - thanks, I have. The quesiton is whether the model we have is the rigth model going forward. I'm pressing on this point quite hard.
Stephanie Perrin:surely abuse at whatever.com<mailto:abuse at whatever.com> is enough?
Greg Shatan:You can never be sure which contact you need or which will work in a given instance.'
Greg Shatan:The one you need is the one that works. Redundancy is an anticipation of failure.
Stephanie Perrin:Rod if you have a virus, heaven help the rest of us....mine keeps crashing.
David Cake:What about the potential issue of needing a contact method other than email in cases where email resolution is the technical issue?
Stephanie Perrin:Registrar has the phone number
Maxim Alzoba (FAITID):aat least two (the other one regulated by transfer policy )
Maxim Alzoba (FAITID):phone lines might be overloaded too
Dick Leaning:so are each registrar ready to recive all the enguires in a timely fashion?
andrew sullivan:@Stephanie: have you ever actually tried to use <abuse at example.com<mailto:abuse at example.com>> or call the registrar to solve a technical problem?
Stephanie Perrin:What happened to clean slate, Maxim? Until we do a PIA on the transfer policy, we are not assured (some of us less than others) that existing policy is legal.
Maxim Alzoba (FAITID):@Dick, this level of redundancy is not piad for
Rod Rasmussen:@Stephanie - I'm sure Michele will love taking those requests!
andrew sullivan:I am getting a little grouchy about people waving away operational experience with "surely this will work"
Dick Leaning:exacty Rod
Maxim Alzoba (FAITID):@Stephanie, I reffered to the current situation where registrars have two phones at least
James Galvin (Afilias):@greg - the question in my mind is whether ICANN (and by extension the rest of us in the system - registries and registrars) is responsible for collecting information to support those use cases?
Fabricio Vayra:+1 Alan
Rod Rasmussen:@Jim - YES it is
Krishna Seeburn - Kris:agreed alan
andrew sullivan:The registration authority for a domain name (at any level of the DNS) is responsible for the delgations it makes
andrew sullivan:and that includes being able to contact the delegated party
James Galvin (Afilias):I have no trouble giving access (which we are not yet talking about) to others to information I already happen to have, I'm just questioning if I should be collecting this information for the reason we are talking about. Does this make sense?
andrew sullivan:and at the top most level, that basically just entails producing a public mechanism to operate it because the common operation of the DNS depends on it
Stephanie Perrin:The more you make the case for the world being malignant or full of nasty people, the more you make the case against a public directory with phone numbers of individuals in it folks
Maxim Alzoba (FAITID):@andrew , delegation on a registry level is technical and responsibility is legal - so it does not work this way
andrew sullivan:@Stephanie: if you don't want to be subect to contact, don't register to operate public-facing infrastructure
andrew sullivan:that's what registering a name under a TLD is
andrew sullivan:you're offering to operate infrastructure at that domain name
Maxim Alzoba (FAITID):and domains work perfectly even in cases of the owners who do not exist anymore (at least for soem time)
Krishna Seeburn - Kris:@andrew....the situation goes both ways....if you have people from EU it changes the whole information that is displayed......
Maxim Alzoba (FAITID):registration is update of records
Dick Leaning:+ 1 Rod
Dick Leaning:if not ICANN, who?
Maxim Alzoba (FAITID):ICANN formally is not responcible for ROs and Rrs ...
Alex Deacon:Relying on magic isn't out of the question....
andrew sullivan:@Krishna: how? Every privacy directive I've anywhere read of includes the ability to publish info necessary for operation
andrew sullivan:this information is necessary for the reliable operation of the distributed database
Maxim Alzoba (FAITID):for simple resolution we need to keep technical and legal things separately
andrew sullivan:the Internet is designed _on purpose_ not to have central choke points
Alan Greenberg:@Rod +100
Lisa Phifer:We are now on slide 9 - data elements identified by DT1
Maxim Alzoba (FAITID):due to simple reason - servers do not know legal codes
andrew sullivan:I am aware that some governments would dearly love for us to reinvent the phone system
andrew sullivan:but that's not the way the Internet is designed
Rod Rasmussen:@Alan - I'll take one for now and use the other 99 later. ;-)
Greg Shatan:Rod, thank you. That point about making things work really well and solving historical problems is what I've been trying to get at, e.g., "better mousetrap" comments in chat.
Lisa Phifer:ow many people would agree that tech issue resolution is a legit pu?rpose for AT MINIMUM resolving issues with DN resolution
Volker Greimann:again: Do you need the name or the snail mail address?
Maxim Alzoba (FAITID):@andrew, in SS7 each country can do whatever they want and it is still working somehow (with huge flows actually)
Marc Anderson:repeat the question please susan
Lisa Phifer:Green check is you agree, red if you disagree
andrew sullivan:SS7 is not distributed in the same way
Fabricio Vayra:can you pls repeat the question?
Lisa Phifer:We still need to discuss data if the issue itself is legitimate
Lisa Phifer:Do you agree that tech issue resolution is a legit purpose for AT MINIMUM resolving issues with DN resolution?
Maxim Alzoba (FAITID):it is too broad
Volker Greimann:legitimate means not illegal, right?
Lisa Phifer:Second question: Do agree that tech issue resolution is a legit purpose for resovling additional issues
Lisa Phifer:Green if you agree, red if you don't
andrew sullivan:if it's dependent on domain name resolution, then it's fine
Maxim Alzoba (FAITID):open ended definition is not a good idea
andrew sullivan:if it's _not_ so dependent, then maybe not
James Galvin (Afilias):my concern is that it is too broad the way the question is stated and the way the definition is currently written.
Sam Lanfranco:depends...
Lisa Phifer:Raise your hand if you disagree and would like to explain why
Stephanie Perrin:I disagree and am tired of explaining why
andrew sullivan:I am green-checking the "dependent service" thing that was my friendly amendment, note
Greg Shatan:There is probably an edge case for Q2 where I would disagree, but for the non-edge, I am a green check,.
Beth Bacon:You need to define what you're using that data element for. If you wan to use it later for other things that needs to be a seperate purposes.
Maxim Alzoba (FAITID):and also about storage of data
Alan Woods (Donuts):+1 beth. We are not defining "purposes" - we are defining uses. They are very different in my opinion
Maxim Alzoba (FAITID):before access
Beth Bacon:+1 Jim
Krishna Seeburn - Kris:+ jim
Stephanie Perrin:Absolutely it is not. Perhaps the only way this is going to be resolved is through a case going to court.
andrew sullivan:I like this formulation better
Stephanie Perrin:How about a couple of "such as" cases.....for those of us who don't understand how the internet works.
Lisa Phifer:Do you agree that tech issue resolution is a legit purpose for resolving additional issues that are directly dependent on DN resolution?
Alan Greenberg:I'm not sure exactly what that means.
Maxim Alzoba (FAITID):resolution is not the only thing which might go south
andrew sullivan:@Stephanie: such as "the mail didn't work because the domain name couldn't resolve"
Rod Rasmussen:This current formulation doesn't preclude broader ones, so I agree with it since its a subset of what I think is proper.
Sam Lanfranco:I may have this wrong but for ungated (public) access a single legitimate purpose is enough. Other purposes are only relevent is use is illegal and that is handled by the LEA process. For gates access this becomes a nightmare...
andrew sullivan:or "I am a help desk person trying to explain to my ISP customer why a domain name went away"
Stephanie Perrin:That one I get Andrew, and see as directly related. I am wondering how far it will stretch....
andrew sullivan:Anything that just depends on name resolution is what is covered
andrew sullivan:and everything that isn't covered possibly by answers from the DNS is not covered
Michael Hammer:What if the technical issue is indirectly related?
andrew sullivan:I think that's the point Jim G was trying to make, and I'm ok with it
andrew sullivan:If it's indirectly related it's by def covered
andrew sullivan:anything that depends on DNS is covered, AIUI
Maxim Alzoba (FAITID):tech issues might be relevant to the same person who registered domain (for example servers overload power grid and it needs to be stopped)
Stephanie Perrin:So if you were coming up with one of those "without restricting the generality of the foregoing" lists what would it include....domain hijacking, domain failing to resolve, email failing to resolve, what else....?
Volker Greimann:then you contact the hoster
Michael Hammer:For example, the enduser browser is compromised and DNS resolution is being modifed (in the browser). The actual resolution is working, for some definition of working but in order to troubleshoot the issue one must comapre what is happening int he client with what is being served from the nameservers. It's abuse, but troubleshooting is a technical issue.
andrew sullivan:sure, they could all be there. Or I am trying to connect to the SIP server and it's not there
andrew sullivan:or whatever.
andrew sullivan:The case that Greg A is outlining would _not_ be covered here
Beth Bacon:What does "agreement" mean today? Are we set in stone or are we simply agreeing to look at this item as a potential legitimate purpose?
andrew sullivan:He's quite right about that -- abuse and so on is lost under the limitation
andrew sullivan:AFAICT "agreement" around here is permanently contingent
Stephanie Perrin:Which raises the question that James has asked, is this ICANN's responsibility to manage?
andrew sullivan:we've never suck on anything so far!
Maxim Alzoba (FAITID):an application can be an issue (on a computer or phone or IoT e.t.c)
Lisa Phifer:Please note slide 3: Any agreement on the legitimacy of one purpose does not preclude additional purposes being agreed as legitimate
Alan Woods (Donuts):*draws attention to Beths Question above
Marc Anderson:lowered my hand since we are basically out of time
Rod Rasmussen:@Alan :-D
andrew sullivan:@Stephanie: no, it does _not_ raise those questions: the resolution case is tailored entirely around JG's point
Tim Chen:great job Susan! tough job....
Stephanie Perrin:But hacking into a server and installing a phishing program surely does?
Lisa Phifer:Possible WG agreement: Tech issue resolution is a legit purpose for AT MINIMUM resolving issues with DN resolution.
andrew sullivan:@Stephanie: those are just outside the resolution case
Greg Shatan:I would like to acknowledge technical issues that are not resolution issues....
Stephanie Perrin:The name continues to resolve, the crime is different, arguably not DNS related...I will refrain from using analogies.
Sam Lanfranco:bye
Lisa Phifer:All, please consider list of criteria on slides 8-9, so we can continue this next week
Maxim Alzoba (FAITID):bye all
Nathalie Coupet:bye
Krishna Seeburn - Kris:thanks bye
andrew sullivan:bye all
Fabricio Vayra:Thanks, Susan!
Marc Anderson:thank you
Daniel K. Nanghaka:Bye
James Galvin (Afilias):Thanks. Good discussion.
Rod Rasmussen:TTFN
Tomslin Samme-Nlar:Thanks all...bye
Susan Kawaguchi:Thanks all!
Greg Shatan:Bye all!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20171121/7786b573/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Attendance RDS PDP 21 Nov.pdf
Type: application/pdf
Size: 14546 bytes
Desc: Attendance RDS PDP 21 Nov.pdf
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20171121/7786b573/AttendanceRDSPDP21Nov-0001.pdf>
More information about the gnso-rds-pdp-wg
mailing list