[gnso-rds-pdp-wg] Attendance, Recordings & AC Chat from Next-Gen RDS PDP WG call on Tuesday, 22 August 2017 at 16:00 UTC
Julie Bisland
julie.bisland at icann.org
Tue Aug 22 19:29:45 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, 22 August 2017 at 16:00 UTC.
MP3: http://audio.icann.org/gnso/gnso-nextgen-rds-pdp-22aug17-en.mp3
AC recording: https://participate.icann.org/p8lgb40xm3d/<https://participate.icann.org/p8lgb40xm3d/?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, 22 August 2017
Julie Bisland:Welcome to the GNSO Next-Gen RDS PDP Working Group call on Tuesday 22 August 2017 at 16:00 UTC.
Julie Bisland:Agenda wiki page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_W2fwAw&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=QiF-05YzARosRvTYd84AB_UYInlydmFcjNmBM5XgySw&m=UJY5nNUfcqHe1jGOQ5c2Pn1XjR1NMgS1dLlgqlW950g&s=I7L9uukyWf_AYrPSIa5fG-keU7znYpdDQJdmn22xcAs&e=
Volker Greimann - RrSG:perfectly
Julie Bisland:ha! thank you, Volker :)
Tim OBrien:hello all
Nathalie Coupet:Hello
Nathalie Coupet:I have to update my SOI: I was appointed Executive Director of Opera Company Brooklyn
steve metalitz:Congratulations Nathalie!
Nathalie Coupet:Thank you!
Nathalie Coupet:Yes
Nathalie Coupet:Thank you, Chuck
sam lanfranco:hello at...in midst of an electrical storm, so my vanish in a flash
Michele Neylon:afternoon
Benjamin Akinmoyeje (Nigeria):Good afternoon
Greg Shatan:Nathalie, will you be in New York City?
Nathalie Coupet:Yes
Amr Elsadr:Marc Anderson's suggested rewording: To improve contactability with the domain name registrant (or authorized agent of the registrant), the RDS must be capable of supporting at least one alternative contact method as an optional field
Greg Shatan:Welcome (assuming you haven't already been here). I live and work in Manhattan (Greenwich Village and Times Square, respectively).
Nathalie Coupet:Wonderful. We'll be doing a lot of Jewish-themed operas and israeli works in Hebrew.
Volker Greimann - RrSG:could we open the document to scrolling, please?
Julie Bisland:you should have scrolling right, Volker.
Julie Bisland:is anyone else having trouble?
Tim OBrien:not just email for alternate contacts
Amr Elsadr:@Alex, could you confirm this as your suggested alternative rewording: In order to provide resiliency to overcome communication failure, at least one alternative electronic contact method (possibly multiple alternative electronic contact methods) MUST be supported by the RDS as an optional field(s)
Alex Deacon:Agree with Steve but I guess it depends on what dedcisions are made in the future regarding postal address and phone contact info.
Krishna Seeburn (Kris):+ 1 steve
Roger Carney:@Steve, I think we need to be careful with more = better
Alex Deacon: @Amr - here is what I suggested - but it may not be relevant or make sense any longer - “In order to provide resiliency to overcome communication failure when using the email address contact method, at least one alternative electronic contact method (possibly multiple alternative electronic contact methods) MUST be supported by the RDS as optional fields.“
Amr Elsadr:Thanks Alex.
Alex Deacon:@Rod - agreed - the issue is that past and even future context is missing and/or unknown.
Greg Shatan:RDS is not a "business" database.
Sara Bockey:Exactly, it IS a business decision.
Greg Shatan:We've always had more than one.
Alex Deacon:Again its difficult (impossible) to have the conversation about "alternative contact methods" in the abstract without understand what contact methods are mandatory. We seem to be going at it backwards.
Tim OBrien:there needs to be alternate contacts for organizations/individuals that have a domain; with each contact having primary and alternate contact methods (with thos ehaving backup/alternate if possible)
James Galvin (Afilias):@alex - i think what I'm understanding is that we want the system to be able to accept a variety of contact methods and that there must be at least one present. does this match what you and others are thinking?
Rod Rasmussen:@Jim - don't have to have more than X contacts (currently 3 - e-mail/phone/physical - fax optional 4), but need to support the ability to handle things like social network contacts, SMS, chat, and future comms methods. People can still make individual decisions on what to provide/support.
Tim OBrien:there is a difference between alternate contacts, and contact methods per each person who is a contact
James Galvin (Afilias):@rod - so, making this concrete - the issue is that the registry must allow for the registrar to provide at least one method of contact and we want the registry to be able to accept all of them.
Alex Deacon:@Jim - I agree that the system must accept a variety of contact methods (in the abstract). - but we can't decide on minimum/mandatory/optional details (concretely) without understanding the mandatory baseline of contact methods.
Greg Shatan:What is the statement?
James Galvin (Afilias):@alex - at the moment i'm also wondering why any particular method has to be mandatory for all? if a registry has to take them all, it might have a policy but it also might be the case that a registrar will make a choice based on what it can do or what it thinks is best for the registrant.
Stephanie Perrin:What is the wording? Apologies for being late
Amr Elsadr:Suggested rewording: To improve contactability with the domain name registrant (or authorized agent of the registrant), the RDS must be capable of supporting at least one alternative contact method as an optional field
Stephanie Perrin:Thanks Alan!
Tim OBrien:Amr Elsadr +1
Amr Elsadr:5 out of 33 WG members object to this statement: To improve contactability with the domain name registrant (or authorized agent of the registrant), the RDS must be capable of supporting at least one alternative contact method as an optional field
Volker Greimann - RrSG:seems like consensus
Volker Greimann - RrSG:rough
Rod Rasmussen:@Jim - Alex's statement is aligned with my current thinking. The regisitry would have a *potentially* higher burden than a registrar to support more "methods" and unique ID's tied to those methods. RDAP should let the physics work fine, but if we don't establish the semantics of what various methods are called, then we could end up with an inconsistency issue. That may be solved by allowing for "free form" naming of comms methods that then get published "as is" for folks to figure out when accessing the data, but that's a whole different topic area to flesh out - probably in implementation .
steve metalitz:@Alan, then what does "as an optional field" mean?
Stephanie Perrin:It is a s ALan has pointed out, a permissiv statement
Maxim Alzoba (FAITID):collecting multiple contacts in situation when a person has only one adds not much to the value of the RDS info
Alex Deacon:We can't have a concrete or useful discussion about optional fields in the abstract.
Sara Bockey:This isn't published info, correct. This is just collected info.
Tim OBrien:But is that system capabilities, or expectations of the contact to provide the information?
Marika Konings:@Sara - correct. This is just about collection, not display.
James Galvin (Afilias):@rod - my model is that the RDS must accept all possible contact methods (list to be defined later but you can imagine email, postal, phone, fax, etc.). What we collect is a separate question. With that in mind,I'm confused by this discussion.
Greg Shatan:Chuck, what do you think this statement means, and what does it favor or disfavor? Still not clear.
Amr Elsadr:Statement in Q3: PBC types identified (Admin, Legal, Technical, Abuse, Proxy/Privacy, Business) must be supported by the RDS but optional for registrants to provide
Fabricio Vayra:Apologies for late arrival -- airplane WIFI has been junk.
Marika Konings:@Alan - if a registrant decides not to provide PCBs doesn't that make the registrant responsible for all queries so it would default to the registrant contact info?
Fabricio Vayra:+1 Marika
Marika Konings:so it is a choice a registrant will need to make, whether or not to delegate some of the responsibilities or take responsibility for all/most?
James Galvin (Afilias):the answer to "what is the value when it has not been provided" is that there must be a default value. The default value is simply copied from something, perhaps the registrant information.
James Galvin (Afilias):the additional roles are provided as a convenience to the registrant who wants to make a distinction.
Alan Greenberg:@Jim, if that is the case and the one contact will be available to anyone woh can get any of the contacts, then fine. But the question does not come anywhere near saying that.
Alex Deacon: So the mandatory to collect purpose based contact is "Registrant".
James Galvin (Afilias):@alan - yes there are policies about collection yet to be discussed. this is just about what the RDS must support.
Marika Konings:Would adding a clarification like the following help: "Should a registrant decide not to provide a separate contact for these PBCs, the registrant contact is expected to deal with queries relating to these purposes identified."
James Galvin (Afilias):@alex - it would seem to be the case that the registrant must be collected. the rest are optional and a convenience for the registrant.
James Galvin (Afilias):@alex - at least that's what I'm thinking
Alex Deacon:@Jim - yes i think we are on the same page.
Marika Konings:or 'Should a registrant decide not to provide a separate contact for these PBCs, the registrant contact will be provided as the default info for these PBCs'?
Fabricio Vayra:+1 Marika. Going further, the "registrant is responsible to deal with"
Stephanie Perrin: I seem to have got Sam's thunderstorm, signal now intermittent. May disappear
Alan Greenberg:Leaving blank is fine EPENDING on the access rules we have not yet discussed.
Alan Greenberg:Depending
Amr Elsadr:Statement now under discussion: PBC types identified (Admin, Legal, Technical, Abuse, Proxy/Privacy, Business) must be supported by the RDS but optional for registrants to provide
Michele Neylon:Alan - that's part of the reason I'm not overly comfortable with getting into some of the really granular details at this point
Fabricio Vayra:+1 Alex
Greg Shatan:+1 Alan
Marika Konings:@Alan - all WG agreements are labelled preliminary and will need to be considered in conjunction which could result in changes / updates.
Michele Neylon:I need to drop - minor issue to deal with here that needs my attention
Stephanie Perrin:Alan, I agree that it is a bit premature to declare consensus. But we have to move forward...
Michele Neylon:sorry
Marika Konings:Greg, with any puzzle, you need to start by putting a few pieces down, otherwise you won't be able to determine which other pieces will fit. But always being ready to start somewhere else or moving around the pieces to make it all fit :-)
Marika Konings:that is the whole purpose of the key concept document - keeping track of preliminary WG agreements which will need to be reviewed to make sure that they all stick together and only then would they get glued :-)
Alan Greenberg:@Marika, That is fine, but I think we should tag the "decision" as contingent on certain specific future decisions.
Marika Konings:@Alan - that is the underlying concept for all our agreements as far as I understand ('iterative process' as Chuck said...)
Amr Elsadr:Note that the Key Concepts Working Draft found here: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_p4xlAw&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=QiF-05YzARosRvTYd84AB_UYInlydmFcjNmBM5XgySw&m=UJY5nNUfcqHe1jGOQ5c2Pn1XjR1NMgS1dLlgqlW950g&s=2KCmLl5xixbe7df910Y_dvBNccKIWjqgejhmP3WFRcA&e= describes the iterative process involved with developing all the WG agreements reached to date.
steve metalitz:Note that we have just "tentatively decided" that item 34, with 45 points (second highest) need not be collected (abuse contact phone).
Volker Greimann - RrSG:@Steve: those are the registrar contacts, right?
Marika Konings:@Steve - the poll asked about which data elements should be included in RDS - the WG agreement is to make to have this available in RDS as an optional field. And note registrar contact info is dealt with on this slide.
steve metalitz:@Volker, no, those are listed separately on "remaining to be considered."
Volker Greimann - RrSG:URL for complaint site should be out
Marika Konings:@STeve - these do refer to the registrar abuse contact email and phone, not registrant
Tim OBrien:all of those should be considered, if not manditory
Volker Greimann - RrSG:not on the phone sorry
Volker Greimann - RrSG:URL for complaint site should be out
Volker Greimann - RrSG:because that is hosting
steve metalitz:@ Marika, OK, that was not clear from the slide.
Marika Konings:Note that the URL of complaint site refers to the INTERNIC site
Volker Greimann - RrSG:content should not be art of the registration data
Marika Konings:which is the ICANN WHOIS Problem Reporting site
Greg Aaaron:No, that has nothingto do with content
Volker Greimann - RrSG:that is a different concept
Volker Greimann - RrSG:we shopuld make that clearer then
Greg Shatan:"regulating content" may be beyond ICANN's mission, "content" is not.
Greg Aaaron:it is for WHOIS accuracy complaints
Volker Greimann - RrSG:I think we need not included it in individual domain data
Volker Greimann - RrSG:as it is the same for every domain
Greg Shatan:Is it the same for every registrant?
Volker Greimann - RrSG:so it can be shown even before the inquiry is made
Greg Aaaron:Is it in there due to a Consensus Poliucy?
Greg Shatan:Is this a collection issue or a display issue?
Volker Greimann - RrSG:@Greg: The internic Link is always the same
Volker Greimann - RrSG:aand not collected from registrant or registrar, just displayed in the whois.
Volker Greimann - RrSG:if it is the internic site, I withdraw my objection here
Marika Konings:as I understand, this specific element is currently required under the 2013 RAA
Greg Shatan:If it needs to be "stored" so it can be "displayed" then it should be in the database.
Volker Greimann - RrSG:Reseller can be problematic
Greg Shatan:If we are using "collection" to mean all methods for adding to the displayable data, then it should be "collected".
Volker Greimann - RrSG:since the registrar does not necessarily know the ultimate reseller
Volker Greimann - RrSG:only his own reseller
Volker Greimann - RrSG:so reseller chains would lead to problems
Maxim Alzoba (FAITID):there could be a chain of resellers
Greg Shatan:I guess the question is where this is being collected from. The registrant should know the ultimate reseller.
Maxim Alzoba (FAITID):and some of them could be registrars
Volker Greimann - RrSG:we provide the data of our reseller, but that is not the point of contact for the customer
Volker Greimann - RrSG:this is not really an edge case, but standards fare
Greg Shatan:If there are intermediate resellers, then that might be an issue. But that's not really an important one.
Stephanie Perrin:This is something that really needs to be cleaned up from a consumer protec tion perspective.
Greg Shatan:The customer should know their point of contact.
Maxim Alzoba (FAITID):it is quite standard thing, given the sale of one of the biggest registrars with the platform for resellers
Volker Greimann - RrSG:Suggestion: "Reseller" as a Yes or no field
Volker Greimann - RrSG:@greg: But the current whois does not do that
Volker Greimann - RrSG:and I would not know how to obtain that information as a registrar
Greg Shatan:That might have some impact on contactability, Volker. :-)
Maxim Alzoba (FAITID):it has impact
Marika Konings:@Volker - how is it currently displayed as it is a required field under the 2013 RAA?
Volker Greimann - RrSG:@Marika: We place the name of our direct reseller (which may not be its trading name).
Tim OBrien:supported sure, but not manditory.
Volker Greimann - RrSG:@Marika: There is no specification of what has to be put there, so we basically put what we have.
Volker Greimann - RrSG:@Marika: And we populate it on a per-reseller base, not a per-domain name base
Marika Konings:the 28 June poll asked about which data elements should be included in RDS - of course, some of that thinking may have evolved based on the deliberations to date ;-)
Rod Rasmussen:Wait, what?
Marika Konings:you may want to conclude that certain alternative methods do not need to be provided for?
Volker Greimann - RrSG:correct: Optional means a provider can ignore this field
Marika Konings:or any / all are to be provided for?
Stephanie Perrin:Some of these decisions are going to be influenced by the legal opinion we are about to get on privacy legal considerations
Stephanie Perrin:The DPAs have pointed out in the past that over collection is an issue. Does not mean tee registrar does not have to collect it. But some elements might not be held in the RDS, let alone displayed or published.
Rod Rasmussen:Any of these should be supported as an optional communication method.
Rod Rasmussen:Again - *optional* and depending upon implementation, you may or may not need specific field names.
Alan Greenberg:There are others of us who are "retired"!
James Galvin (Afilias):so how about an optional "other" field that is free-form syntax. it could even be multi-valued (i.e., you can have more than one)
Alan Greenberg:Have to leave now.
Rod Rasmussen:Perhaps we can rule out semaphore and smoke signals as optional contact methods, but otherwise, we should be looking to provide flexibilty and accept new methods rather than ruling out useful comms methods.
Volker Greimann - RrSG:Myspace? Lets make Geocities addresses mandatory!
Greg Shatan:Prodigy
Greg Shatan:Delphi
Greg Shatan:Yahoo AIM
Rod Rasmussen:I hear usenet is still a thing.
Volker Greimann - RrSG:Napster chat account names (old napster, obviously)
Greg Shatan:IRC
Sara Bockey:whoa...time warp overload!
Tapani Tarvainen:+1 Greg - I still use IRC :-)
Maxim Alzoba (FAITID):any gopher fans?
Nathalie Coupet:gopher yes
Greg Shatan:When I started working, my first firm still had its cable and telex addresses on its letterhead. That was 1986.
Tim OBrien:ARPA Uids
Maxim Alzoba (FAITID):bye all
James Galvin (Afilias):bye all. thanks.
Nathalie Coupet:bye
Sara Bockey:thanks all
Benjamin Akinmoyeje(Nigeria):thank you
Greg Shatan:Bye all!
Juan Manuel Rojas:Thanks all. Bye
Rod Rasmussen:TTFN
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170822/1a412599/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Attendance RDS PDP 22 August.pdf
Type: application/pdf
Size: 336915 bytes
Desc: Attendance RDS PDP 22 August.pdf
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170822/1a412599/AttendanceRDSPDP22August-0001.pdf>
More information about the gnso-rds-pdp-wg
mailing list