{ "session_id": "icann87-sched-2WjfE", "canonical_id": "icann87-sched-2WjfE", "segments": [ { "start": 3.08, "end": 21.539, "text": "ICANN - MTS - A/V: Hello, and welcome to the DNS Abuse Mitigation PDP-1 Working Group Session 2 of 4. Please note that this session is being recorded and is governed by the ICANN Expected Standards of Behavior, the ICANN Community Anti-Harassment Policy, and the ICANN Community Participant Code of Conduct Concerning Statements of Interest." }, { "start": 21.71, "end": 39.059, "text": "ICANN - MTS - A/V: Please observe the guidelines to participate in this session. I will also post them in the chat for your reference. If you wish to speak, please raise your hand in Zoom or otherwise as directed. When speaking, please state your name for the record and speak clearly and at a moderate pace. With that, I'll hand the floor over to Paul McGrady. Please begin." }, { "start": 40.58, "end": 44.289, "text": "ICANN - MTS - A/V: Thank you, Terry. Welcome, everyone, to Session 2." }, { "start": 44.39, "end": 46.88, "text": "ICANN - MTS - A/V: of PDP1?" }, { "start": 47.34, "end": 52.59, "text": "ICANN - MTS - A/V: We retained part of our crowd. How about that? We must have been very enthralling." }, { "start": 52.82, "end": 56.09, "text": "ICANN - MTS - A/V: We are going to be going through" }, { "start": 56.3, "end": 61.369, "text": "ICANN - MTS - A/V: Recs 3 and 4, along with implementation guidance." }, { "start": 61.62, "end": 69.989, "text": "ICANN - MTS - A/V: 3.1 and 4.1 In this session, so… Let's get started." }, { "start": 71.72, "end": 72.44, "text": "ICANN - MTS - A/V: Bam." }, { "start": 73.81, "end": 84.32, "text": "ICANN - MTS - A/V: Hi, everyone, welcome back. As noted by Paul, as you see on the screen, the main comments received on Recommendation 3 that leadership thought" }, { "start": 84.61, "end": 95.969, "text": "ICANN - MTS - A/V: could be implemented, considered in the language update, or, clarify what reasonably accessible information encompass in more specificity. We know that the group talked about this" }, { "start": 96.0, "end": 106.649, "text": "ICANN - MTS - A/V: in the past, and it was quite strong compromise. However, I think there might be some changes justified to just explain the notion a bit better." }, { "start": 106.65, "end": 119.84899999999999, "text": "ICANN - MTS - A/V: Similarly, another cluster of public comment noted clarity or clarify reseller held information, registrar responsibility. So in the following slide, Paul will introduce how" }, { "start": 119.87, "end": 122.829, "text": "ICANN - MTS - A/V: That could look like, in terms of language, we hope." }, { "start": 123.05, "end": 124.98, "text": "ICANN - MTS - A/V: that would address it. Back to Paul." }, { "start": 126.5, "end": 128.31, "text": "ICANN - MTS - A/V: Thank you. Fail. Okay." }, { "start": 128.72899999999998, "end": 137.26, "text": "ICANN - MTS - A/V: This is a proposed, language update to Rec 3, based upon, as you guys saw." }, { "start": 137.47, "end": 142.19, "text": "ICANN - MTS - A/V: Comments from lots of people saying we need to do some clarification here." }, { "start": 142.3, "end": 148.82999999999998, "text": "ICANN - MTS - A/V: It's considered a substantive Comment, or reason… so let's jump into it." }, { "start": 149.25, "end": 154.139, "text": "ICANN - MTS - A/V: The updated REC proposal I'll read it." }, { "start": 154.47, "end": 169.389, "text": "ICANN - MTS - A/V: A reasonable investigation by a registrar must consist of reviewing information reasonably accessible to the registrar in the normal course of its operations to determine whether associated domain names are being used for DNS abuse." }, { "start": 169.62, "end": 174.45, "text": "ICANN - MTS - A/V: As defined in 3.18.1 of the RAA." }, { "start": 174.68, "end": 183.229, "text": "ICANN - MTS - A/V: For the purposes of this recommendation, information reasonably accessible to the Registrar includes, but is not limited to, and here's the change." }, { "start": 183.47, "end": 187.56, "text": "ICANN - MTS - A/V: Information the Registrar is required to collect or maintain." }, { "start": 187.71, "end": 193.32, "text": "ICANN - MTS - A/V: Under its contractual obligations, Information available through its technical systems." }, { "start": 193.47, "end": 202.07999999999998, "text": "ICANN - MTS - A/V: and reasonably accessible to it directly or through resellers and information and records contained in abuse reports it receives." }, { "start": 203.03, "end": 208.519, "text": "ICANN - MTS - A/V: So, that's the proposed change. We're going to open a queue on this. Reg, please go ahead." }, { "start": 211.48, "end": 215.41899999999998, "text": "Reg Levy – Tucows: Thank you. Reg Levy from the Registrars and 2CAS." }, { "start": 215.82999999999998, "end": 224.699, "text": "Reg Levy – Tucows: I feel like we went over this many, many, many, many times and moved away from this, so it's kind of frustrating to see it back again." }, { "start": 225.1, "end": 226.14, "text": "Reg Levy – Tucows: Umm." }, { "start": 226.64, "end": 227.45, "text": "Reg Levy – Tucows: Yeah." }, { "start": 227.95, "end": 229.11, "text": "Reg Levy – Tucows: That's where I am." }, { "start": 231.19, "end": 232.94, "text": "ICANN - MTS - A/V: Thanks, Reg." }, { "start": 233.99, "end": 240.05, "text": "ICANN - MTS - A/V: And remember, this is just a straw person. If nobody wants to make any changes, we don't have to make any changes." }, { "start": 246.06, "end": 247.689, "text": "ICANN - MTS - A/V: Mark Trachtenberg for the IPC." }, { "start": 248.04, "end": 250.26, "text": "ICANN - MTS - A/V: This language looks good." }, { "start": 250.38, "end": 254.89, "text": "ICANN - MTS - A/V: to me, and I think would be acceptable to the IPC. I take Reg's point about how this was discussed." }, { "start": 255.36, "end": 256.17, "text": "ICANN - MTS - A/V: A lot." }, { "start": 256.43, "end": 273.569, "text": "ICANN - MTS - A/V: During the working group sessions, and it was, but there's a reason we have public comment, which is to solicit feedback from everyone. I mean, we have people that are representative of the different communities, but not everyone participates in the actual discussions and has access to everything, and so that's why we put it out for public comment. And there was substantial public comment on this issue." }, { "start": 274.46, "end": 285.289, "text": "ICANN - MTS - A/V: you know, raise some of these points that also were raised during our discussion. So, I think that the public comments show that there is a lot of interest in this, and that this was a hole, and that maybe here, the group didn't get it right." }, { "start": 287.24, "end": 289.359, "text": "ICANN - MTS - A/V: Thank you, Mark Volker." }, { "start": 290.18, "end": 292.9, "text": "ICANN - MTS - A/V: Yeah, Volker Kleiman, RRSG." }, { "start": 293.90999999999997, "end": 296.329, "text": "ICANN - MTS - A/V: I share a registered position that." }, { "start": 296.51, "end": 314.19, "text": "ICANN - MTS - A/V: We have been over this time and again, and really, this seems like a second bite of the apple by those that didn't get what they wanted originally. I also seem to recall, when I looked at the chart of support of the original recommendations, that the original recommendations had very high levels of support, and there was" }, { "start": 314.26, "end": 322.239, "text": "ICANN - MTS - A/V: a significantly lower amount of people that want to change and had significant issues with that, so I would see this as a minor position, and" }, { "start": 322.3, "end": 335.75, "text": "ICANN - MTS - A/V: The majority seems to be, of the commenters as well, and of the people that previously decided on the language that we had before, and that that language that we had before was the way to go, and the ideal solution. So I would." }, { "start": 336.13, "end": 345.209, "text": "ICANN - MTS - A/V: say that if this was something that was basically proposed by a majority of the commenters, then we should probably consider this. But if it's only a minority, then." }, { "start": 345.84000000000003, "end": 347.28, "text": "ICANN - MTS - A/V: Yeah, we've been over it." }, { "start": 348.83, "end": 350.179, "text": "ICANN - MTS - A/V: Thank you. Volker." }, { "start": 350.32, "end": 357.07, "text": "ICANN - MTS - A/V: And just to, Bring in some facts to support the" }, { "start": 357.32, "end": 365.6, "text": "ICANN - MTS - A/V: concerns that we've been over it, because I'm not trying to put my thumb on the scale, but we're not… for those in the room that maybe weren't on all the working group calls, we did talk about this." }, { "start": 366.0, "end": 369.39, "text": "ICANN - MTS - A/V: On April 13th, May 4th." }, { "start": 369.91, "end": 372.939, "text": "ICANN - MTS - A/V: At ICANN 86 in sessions 1 and 2." }, { "start": 373.1, "end": 377.899, "text": "ICANN - MTS - A/V: ICANN 86 is sessions 3 and 4. We talked about it again on the 22nd of June." }, { "start": 378.05, "end": 382.99, "text": "ICANN - MTS - A/V: July 13th and August 3rd. So we have talked about this quite a bit." }, { "start": 383.27, "end": 389.07, "text": "ICANN - MTS - A/V: So, I… Again, the language that we have out here is just a…" }, { "start": 389.37, "end": 391.809, "text": "ICANN - MTS - A/V: Straw person, in an attempt to…" }, { "start": 392.01, "end": 395.73, "text": "ICANN - MTS - A/V: respond to the public comment. And" }, { "start": 395.89, "end": 402.299, "text": "ICANN - MTS - A/V: So far, we've got some support for, others saying we've… without…" }, { "start": 402.94, "end": 410.04, "text": "ICANN - MTS - A/V: necessarily saying there's anything wrong with the new language, just saying that, you know, we've been over it. Sounds like a second bite at the apple." }, { "start": 410.29, "end": 413.159, "text": "ICANN - MTS - A/V: We're gonna go to Martina, and go ahead." }, { "start": 414.11, "end": 423.6, "text": "ICANN - MTS - A/V: Thank you very much, Paul Martina, representing the GAC for the records. I mean, I think as the GAC, we were fine and accepted the previous language, but this specific comment comes from ICANN Org." }, { "start": 424.02, "end": 434.1, "text": "ICANN - MTS - A/V: So that puts me in a very uncomfortable chair, because if ICANNORC tells me that I should be worried about this language, then I'm double guessing myself, of course, and I would like to hear from the registrars" }, { "start": 434.39, "end": 443.33, "text": "ICANN - MTS - A/V: Because we have trusted ICANN Org's judgment on a number of occasions, so maybe ICANN can explain why the comment came through, and the register can develop on," }, { "start": 443.43, "end": 446.2, "text": "ICANN - MTS - A/V: What's their interpretation of this concern from Eigenorg?" }, { "start": 447.06, "end": 457.009, "text": "ICANN - MTS - A/V: Thanks, Martina. We have a representative of ICANN Org, and since we've used their name, why don't we ask them why they've asked for this change, what the enhancement is?" }, { "start": 458.12, "end": 463.96, "text": "ICANN - MTS - A/V: Sure, Peter Rieken ICANN Org. So, I just want to clarify, this is a drafting clarification." }, { "start": 464.4, "end": 473.139, "text": "ICANN - MTS - A/V: So, we're not seeking to change the standard of a reasonably accessible information, or tell registers how to conduct." }, { "start": 473.31, "end": 479.45, "text": "ICANN - MTS - A/V: Their investigations, but to us, The, sort of, the current language of" }, { "start": 479.7, "end": 483.149, "text": "ICANN - MTS - A/V: Contractual obligations, technical systems, research reports." }, { "start": 483.44, "end": 486.52, "text": "ICANN - MTS - A/V: Was… wasn't precise, it wasn't particularly clear." }, { "start": 486.66, "end": 495.619, "text": "ICANN - MTS - A/V: What that meant. So, we wanted to clarify that our understanding, right, was that that covers information that registrars are required to collect." }, { "start": 496.05, "end": 509.939, "text": "ICANN - MTS - A/V: through their own systems, or resellers, and information about the abuse reports that they received. So the aim of this was to make the scope of the standard clearer, without changing what registers are required to do, or prescribe how they do it." }, { "start": 510.44, "end": 512.409, "text": "ICANN - MTS - A/V: So if that potentially helps." }, { "start": 515.559, "end": 523.449, "text": "ICANN - MTS - A/V: I guess I'm going to be mean to you, hope you don't mind. What is in here that would not make its way into a contractual" }, { "start": 523.72, "end": 528.719, "text": "ICANN - MTS - A/V: compliance, you know, guideline, because you're gonna… at the end of implementation." }, { "start": 529.28, "end": 534.199, "text": "ICANN - MTS - A/V: there'll be… Some documents that go to registrars to explain what the new obligations are." }, { "start": 534.62, "end": 538.099, "text": "ICANN - MTS - A/V: Is there something about the initial definition that would" }, { "start": 538.32, "end": 540.66, "text": "ICANN - MTS - A/V: Tie your hands in that, or…" }, { "start": 541.26, "end": 546.209, "text": "ICANN - MTS - A/V: I mean, is this the only place this can be, is what I'm asking, or could it be downstream someplace else?" }, { "start": 547.29, "end": 552.899, "text": "ICANN - MTS - A/V: I mean, potentially, we are really just commenting on the recommendation." }, { "start": 553.04, "end": 571.679, "text": "ICANN - MTS - A/V: So, obviously, in implementation, when it comes to discussing how to turn this into consensus policy, it helps to be as precise as possible, because often these arguments become, you know, they're revived, and people start, people in the IRT representative start to say no, but when we meant, what we meant by this was." }, { "start": 572.0, "end": 576.83, "text": "ICANN - MTS - A/V: Okay, so… Our understanding was that this is what the working group." }, { "start": 577.56, "end": 581.4590000000001, "text": "ICANN - MTS - A/V: tended by this definition. So, where possible." }, { "start": 581.6, "end": 587.73, "text": "ICANN - MTS - A/V: We were asking if this is what the working group intended, maybe it's best Just to state it clearly." }, { "start": 588.21, "end": 592.699, "text": "ICANN - MTS - A/V: So, it involves, potentially revisiting this and implementation." }, { "start": 593.01, "end": 599.629, "text": "ICANN - MTS - A/V: However, it is a refinement change. It's really just to improve the clarification. We're not, suggesting, like, a change of approach." }, { "start": 599.89, "end": 600.55, "text": "ICANN - MTS - A/V: somewhere." }, { "start": 601.01, "end": 602.76, "text": "ICANN - MTS - A/V: All right, thank you. Chris?" }, { "start": 603.71, "end": 610.119, "text": "ICANN - MTS - A/V: Thank you, Paul. And thanks, Peter, for clarifying it." }, { "start": 610.59, "end": 616.119, "text": "ICANN - MTS - A/V: I originally put my hand up to ask what was the justification for the wording." }, { "start": 617.04, "end": 618.72, "text": "ICANN - MTS - A/V: Having listened to you." }, { "start": 620.03, "end": 624.29, "text": "ICANN - MTS - A/V: I suppose my comment would be that I'm not sure that it is just a clarification." }, { "start": 626.17, "end": 634.33, "text": "ICANN - MTS - A/V: What… the sentence that's been… or the words that have been removed say, information ordinarily accessible to the registrar through its contractual obligations." }, { "start": 634.6, "end": 642.16, "text": "ICANN - MTS - A/V: What you've said is information the registrar is required to collect or maintain, so you have removed the ordinarily accessible." }, { "start": 642.39, "end": 650.35, "text": "ICANN - MTS - A/V: And it's entirely possible it could be information that the registrar was contractually obliged to collect 6 years ago." }, { "start": 650.58, "end": 652.87, "text": "ICANN - MTS - A/V: Which is no longer ordinarily accessible." }, { "start": 653.18, "end": 655.4, "text": "ICANN - MTS - A/V: So I do think it makes a change." }, { "start": 655.86, "end": 660.019, "text": "ICANN - MTS - A/V: By removing the reference to ordinarily accessible." }, { "start": 660.99, "end": 664.02, "text": "ICANN - MTS - A/V: Do you think that…" }, { "start": 664.43, "end": 669.649, "text": "ICANN - MTS - A/V: Was ordinarily accessible a problem for you? Is that why you asked for the change?" }, { "start": 671.19, "end": 672.01, "text": "ICANN - MTS - A/V: Thank you." }, { "start": 676.35, "end": 678.27, "text": "ICANN - MTS - A/V: I think we were just, I think…" }, { "start": 678.39, "end": 682.079, "text": "ICANN - MTS - A/V: When we were looking at this, we were trying to unpack exactly what was meant." }, { "start": 682.61, "end": 683.48, "text": "ICANN - MTS - A/V: So." }, { "start": 683.86, "end": 687.659, "text": "ICANN - MTS - A/V: For us, the original information ordinarily accessible." }, { "start": 688.39, "end": 705.02, "text": "ICANN - MTS - A/V: through its contractual obligations, it wasn't quite clear what that meant. It obviously could vary technical systems and boost reports. So, we were trying just to make, you know, based on our understanding of what the working group intended, obviously." }, { "start": 705.45, "end": 709.889, "text": "ICANN - MTS - A/V: What you're saying is this is not what you intended. Take that on board." }, { "start": 710.82, "end": 717.049, "text": "ICANN - MTS - A/V: We just wanted, maybe just… Just to be quite clear, you know, we think this is what you mean." }, { "start": 717.37, "end": 723.25, "text": "ICANN - MTS - A/V: So, I take your point if this is… if you think this language is not representative." }, { "start": 725.2, "end": 727.56, "text": "ICANN - MTS - A/V: Thank you. Okay, we have Mark." }, { "start": 728.75, "end": 730.559, "text": "ICANN - MTS - A/V: Mark Trachtenberg of the IPC." }, { "start": 731.07, "end": 735.66, "text": "ICANN - MTS - A/V: We did discuss this a lot, and there was some significant disagreement, and there was some compromise here." }, { "start": 735.78, "end": 736.69, "text": "ICANN - MTS - A/V: Right, so…" }, { "start": 737.29, "end": 742.72, "text": "ICANN - MTS - A/V: But even though the window's compromised, I think people have the ability to still make public comments to put their views on the record of what they think it should be, and…" }, { "start": 742.87, "end": 750.489, "text": "ICANN - MTS - A/V: I think on this one, part of what we discussed is, well, why do we have to be so precise here? I can't compliance, we'll figure it out, and they'll tell us in an advisory." }, { "start": 750.53, "end": 765.979, "text": "ICANN - MTS - A/V: Well, now we don't have to wait. Now they're telling us how they view it. They're telling us what they view, and so they're telling us already, why put it in an advisory? Why not just be clear and put it in a policy? And again, I think we should be as clear as possible in this policy when available, and so ICANN is now telling us their view. Let's just bake it into this and be done." }, { "start": 767.63, "end": 769.18, "text": "ICANN - MTS - A/V: Thank you, Mark Volker." }, { "start": 770.83, "end": 772.62, "text": "ICANN - MTS - A/V: Yes, I think," }, { "start": 773.03, "end": 788.899, "text": "ICANN - MTS - A/V: we have been over this numerous times, and we had… I mean, this was one of the longer discussions that we had during the working group, and I think Reg is right when she puts in the chat that the working group intended what the working group proposed, and that was the… that was the intent, that was the language that we ultimately agreed on, and I think… I find it kind of…" }, { "start": 789.27, "end": 801.149, "text": "ICANN - MTS - A/V: Sad is the right word, it isn't the right word, but, curious that ICANN, who was in the room and who was asked to contribute and weigh in on the suggestions that we made during the time that we discussed them." }, { "start": 801.37, "end": 819.079, "text": "ICANN - MTS - A/V: chose to wait with their feedback until now. I think that feedback would have been valuable and interesting at the time that we discussed it, and it could have been maybe even influenced the decision of the working group, but it was missing. Why did ICANN not make these comments?" }, { "start": 819.2, "end": 823.32, "text": "ICANN - MTS - A/V: And voice these concerns, or bring forth these issues." }, { "start": 823.47, "end": 825.91, "text": "ICANN - MTS - A/V: At the time that we asked them to contribute them." }, { "start": 826.02, "end": 832.279, "text": "ICANN - MTS - A/V: I think… That, to me, is sad and a break in the process that could have been avoided." }, { "start": 833.85, "end": 836.15, "text": "ICANN - MTS - A/V: Thanks, Volker. I do want to say, however, that" }, { "start": 837.03, "end": 845.15, "text": "ICANN - MTS - A/V: that ICANN Org is also a member of the multi-stakeholder community, right? And under…" }, { "start": 845.34, "end": 851.25, "text": "ICANN - MTS - A/V: And under that theory, we could dismiss any public comment by anybody that had a representative around the table." }, { "start": 851.45, "end": 857.71, "text": "ICANN - MTS - A/V: Right? So we don't… I don't think we want to do that, but I… but I will acknowledge your frustration. How's that? I can do that." }, { "start": 858.1, "end": 860.159, "text": "ICANN - MTS - A/V: Reg, go ahead." }, { "start": 861.31, "end": 867.77, "text": "Reg Levy – Tucows: Thanks, and… As has been said, this… the verbiage was…" }, { "start": 867.93, "end": 871.08, "text": "Reg Levy – Tucows: The result of a lot of backing and forcing." }, { "start": 871.58, "end": 877.699, "text": "Reg Levy – Tucows: And… It feels very much like that has been tossed out the window." }, { "start": 877.93, "end": 881.849, "text": "Reg Levy – Tucows: Information ordinarily accessible." }, { "start": 882.33, "end": 887.009, "text": "Reg Levy – Tucows: Was put first, very specifically because…" }, { "start": 887.12, "end": 892.619, "text": "Reg Levy – Tucows: There is information that we are required to have that is not easily accessible." }, { "start": 893.22, "end": 901.929, "text": "Reg Levy – Tucows: And so, although we have that under our contractual obligations, and when ICANN asks us for it, we can pull that data, that's very different" }, { "start": 901.93, "end": 913.99, "text": "Reg Levy – Tucows: From a, hopefully, reasonably quick and easy look at our files to say, okay, is there anything here that we can compare to something else that we have?" }, { "start": 914.4, "end": 923.749, "text": "Reg Levy – Tucows: And… For example, I'm gonna say the entire who is history of a domain." }, { "start": 924.14, "end": 934.24, "text": "Reg Levy – Tucows: That may not be ordinarily accessible, and so I'm not going to compare all of the information that it used to have." }, { "start": 935.37, "end": 938.11, "text": "Reg Levy – Tucows: I will compare what is currently available." }, { "start": 938.61, "end": 939.71, "text": "Reg Levy – Tucows: And…" }, { "start": 940.13, "end": 956.619, "text": "Reg Levy – Tucows: Maybe that's… maybe that's an extreme lack, and we definitely want to make sure that a domain that transferred in that is very old, that we're still looking at every single piece of everything, but… but the point of putting information ordinarily accessible" }, { "start": 956.84, "end": 960.649, "text": "Reg Levy – Tucows: First was saying that that's the important piece." }, { "start": 960.92, "end": 963.659, "text": "Reg Levy – Tucows: That we have systems." }, { "start": 964.2, "end": 978.859, "text": "Reg Levy – Tucows: that allow us to access certain pieces of data, and that's what we're going to use, and that may differ based on what the registrar is. And as Volker said in the chat, this has been gotten over and over and over again." }, { "start": 978.94, "end": 990.15, "text": "Reg Levy – Tucows: And so it is a little bit frustrating to do it again. I'm happy to continue to fight this, but again, I thought we had gotten to a place where everybody was a little bit unhappy." }, { "start": 991.3, "end": 993.85, "text": "Reg Levy – Tucows: Which is the point of a true compromise." }, { "start": 994.68, "end": 996.679, "text": "ICANN - MTS - A/V: Thank you, Reg." }, { "start": 997.13, "end": 1004.659, "text": "ICANN - MTS - A/V: Yeah, we did discuss it, for sure. Things are not thrown out the window. This is straw people text. We're… nobody is obligated" }, { "start": 1004.87, "end": 1008.98, "text": "ICANN - MTS - A/V: to accept what Nick and I did to try to bring the…" }, { "start": 1009.12, "end": 1012.59, "text": "ICANN - MTS - A/V: public comments in, so nothing's out the window. We're just… we're…" }, { "start": 1012.73, "end": 1018.449, "text": "ICANN - MTS - A/V: taking comments on the text and the temperature of the room about whether or not we want to adopt it, right? That's all." }, { "start": 1018.74, "end": 1021.78, "text": "ICANN - MTS - A/V: Chris, go ahead." }, { "start": 1023.05, "end": 1025.05, "text": "ICANN - MTS - A/V: Thank you, Paul." }, { "start": 1027.599, "end": 1036.25, "text": "ICANN - MTS - A/V: I don't… I don't think it's particular… I understand the frustration, but I don't think it's particularly relevant to this discussion whether or not it should have been said in the room weeks ago." }, { "start": 1036.7, "end": 1051.27, "text": "ICANN - MTS - A/V: But equally, I don't think that putting up the text without some clear explanation as to what's wrong with the existing text is actually a fair way of dealing with it. So if ICANN Org believes that the text that was originally there is unclear." }, { "start": 1051.27, "end": 1059.5, "text": "ICANN - MTS - A/V: I would like an explanation of what it is that is unclear about it and why it is that their suggested text is better." }, { "start": 1059.73, "end": 1061.99, "text": "ICANN - MTS - A/V: Given that they are being… given that…" }, { "start": 1062.34, "end": 1068.469, "text": "ICANN - MTS - A/V: Faced with a number of people in this room saying, It doesn't… it does… it…" }, { "start": 1068.58, "end": 1082.57, "text": "ICANN - MTS - A/V: It changes the import of the sentence. You're going to need to explain what the problem was with the wording you had and why you think your wording is better. I don't think it's enough to simply say this is what we think is better. You need to say why." }, { "start": 1085.09, "end": 1088.7, "text": "ICANN - MTS - A/V: Thanks, Chris. So yeah, this is…" }, { "start": 1088.93, "end": 1092.819, "text": "ICANN - MTS - A/V: An attempt to respond to the public comment, if there is a champion." }, { "start": 1093.2, "end": 1096.289, "text": "ICANN - MTS - A/V: For our straw person, happy to…" }, { "start": 1096.48, "end": 1099.759, "text": "ICANN - MTS - A/V: Hear from them. We've heard from people who," }, { "start": 1100.34, "end": 1104.76, "text": "ICANN - MTS - A/V: Pointing back to how many times we've talked about this, and the fact that it was a subject of compromise." }, { "start": 1105.0, "end": 1116.42, "text": "ICANN - MTS - A/V: So if we are going to change this, even though Nick and I proposed it, and you know, because we're trying to bring in the public's comment, right? This isn't just about what we've all said around the table." }, { "start": 1116.55, "end": 1118.389, "text": "ICANN - MTS - A/V: I'm not married to this." }, { "start": 1118.5, "end": 1135.56, "text": "ICANN - MTS - A/V: Right? But if somebody thinks this is better, or if they think if there's something even different than this that's better, great, let's hear. But Chris, I think that your request that somebody… that anybody that wants to make a change should be able to defend it, I think that's fair. We're gonna hear from Ching." }, { "start": 1136.19, "end": 1139.919, "text": "ICANN - MTS - A/V: Thank you, Paul. Ching from the BC. So, I'd like to make a short point on" }, { "start": 1140.47, "end": 1147.02, "text": "ICANN - MTS - A/V: the information, right? So, I think… I'm just guessing that ICANN wants more information." }, { "start": 1147.26, "end": 1165.499, "text": "ICANN - MTS - A/V: But at this particular case, more information is not necessarily useful. The right information is more useful, so I would rather, or the BC would probably rather to spend time on getting the right information instead of just more information." }, { "start": 1165.75, "end": 1168.9, "text": "ICANN - MTS - A/V: This is what I'm trying to get at. Thank you." }, { "start": 1169.28, "end": 1174.27, "text": "ICANN - MTS - A/V: Thanks, Ching. So, help me understand, is that support going back to the old, or…" }, { "start": 1174.63, "end": 1188.65, "text": "ICANN - MTS - A/V: What are you advocating for? At this point, I would rather to stick with the old one, so we don't go there. But if we're going to, for example, if the IRT want to talk about what information means, I'll be happy to." }, { "start": 1188.9, "end": 1194.19, "text": "ICANN - MTS - A/V: Do it in terms of setting what's right for, you know, the information that we'd like to collect." }, { "start": 1194.77, "end": 1195.839, "text": "ICANN - MTS - A/V: Thank you, Ching." }, { "start": 1196.0, "end": 1197.51, "text": "ICANN - MTS - A/V: Back to you, Mark." }, { "start": 1199.44, "end": 1201.23, "text": "ICANN - MTS - A/V: Mark Trachtenberg, the IPC." }, { "start": 1202.03, "end": 1204.87, "text": "ICANN - MTS - A/V: If this is ICANN's view, Right?" }, { "start": 1205.29, "end": 1209.639, "text": "ICANN - MTS - A/V: why put it in an advisory and just not put it into the policy? Because ultimately." }, { "start": 1210.1, "end": 1211.91, "text": "ICANN - MTS - A/V: If they put it into an advisory." }, { "start": 1212.43, "end": 1219.529, "text": "ICANN - MTS - A/V: That's what's required anyway, but now you're just adding another level of another place that people have to look instead of just baking it into the policy itself." }, { "start": 1219.87, "end": 1222.26, "text": "ICANN - MTS - A/V: So it just seems way more efficient if that's what they want." }, { "start": 1222.56, "end": 1224.25, "text": "ICANN - MTS - A/V: Like, whether people agree with it or not." }, { "start": 1224.5, "end": 1225.37, "text": "ICANN - MTS - A/V: you know." }, { "start": 1226.49, "end": 1234.17, "text": "ICANN - MTS - A/V: Parties acknowledge that we have to go with what compliance says. We've said it a million times, what would align compliance? Well, now compliance and ICANN is telling you this is what we need, this is how we view it." }, { "start": 1234.4, "end": 1239.88, "text": "ICANN - MTS - A/V: Why make people go to a different document, a different advisory, when it could just be in the policy itself? That seems inefficient to me." }, { "start": 1241.29, "end": 1242.629, "text": "ICANN - MTS - A/V: And I think this language is fine." }, { "start": 1244.45, "end": 1245.41, "text": "ICANN - MTS - A/V: Martina." }, { "start": 1246.47, "end": 1255.34, "text": "ICANN - MTS - A/V: Thank you very much, Paul, and I hear all sides around this table, I understand the frustration, but again, from a policy perspective, government perspective." }, { "start": 1255.6, "end": 1263.98, "text": "ICANN - MTS - A/V: We can be a bit concerned if ICANN Org does not feel like the text is adequate, but maybe I think ICANN Org initial interpretation of what we meant." }, { "start": 1264.07, "end": 1272.779, "text": "ICANN - MTS - A/V: It's not what we meant, so now they… we have repeated what we meant, what we mean, so maybe there's a better phrasing that can be put on the table that" }, { "start": 1272.85, "end": 1284.599, "text": "ICANN - MTS - A/V: respects the compromise, the spirits of the compromise that we've reached without reopening the entire discussion, but it's not exactly the text that is here, so maybe I would put that in the hands of ICANNOR to" }, { "start": 1284.89, "end": 1290.05, "text": "ICANN - MTS - A/V: Briefly, you know, think about that. I think there would be something else textually could be." }, { "start": 1290.35, "end": 1299.0, "text": "ICANN - MTS - A/V: played with to ensure that they're fine enough for implementing the policy, but as I said, we would like ICANN to tell us that it is fine." }, { "start": 1301.19, "end": 1302.909, "text": "ICANN - MTS - A/V: Thanks, Martina. Reg." }, { "start": 1305.06, "end": 1306.49, "text": "Reg Levy – Tucows: Thank you." }, { "start": 1307.22, "end": 1317.379, "text": "Reg Levy – Tucows: Since this is something that had been discussed so often, and to Tomas's, point in the chat, that should be taken into account with public comments." }, { "start": 1317.56, "end": 1326.139, "text": "Reg Levy – Tucows: The only way that I could live with this would be if it said, may include, but is not limited to." }, { "start": 1332.13, "end": 1340.7, "text": "ICANN - MTS - A/V: So it would read, \"Reasonably accessible to the registrar may include.\" But it's not limited to." }, { "start": 1341.52, "end": 1343.39, "text": "ICANN - MTS - A/V: And then the rest of it stays." }, { "start": 1343.79, "end": 1345.17, "text": "ICANN - MTS - A/V: The way it's written now?" }, { "start": 1346.41, "end": 1348.46, "text": "Reg Levy – Tucows: Don't love it, but I could live with it." }, { "start": 1349.0, "end": 1357.009, "text": "Reg Levy – Tucows: I think, honestly, since we've done this so many times, that what we had before is preferable, but that seems to not be a popular position." }, { "start": 1358.86, "end": 1359.68, "text": "ICANN - MTS - A/V: Thanks Reg." }, { "start": 1360.45, "end": 1361.91, "text": "ICANN - MTS - A/V: Brian." }, { "start": 1362.34, "end": 1381.46, "text": "ICANN - MTS - A/V: Thanks, Paul. Just to note, I think that what Reg proposed sounds reasonable. But I think it might be helpful, too, to understand the change that, you know, because I understand that this came from a comment maybe from ICANN Org, but there's obviously various parts of ICANN Org. And so, is this something that actually came from compliance" }, { "start": 1381.69, "end": 1385.12, "text": "ICANN - MTS - A/V: As far as a, they need this in order to" }, { "start": 1385.56, "end": 1388.489, "text": "ICANN - MTS - A/V: From an enforceability perspective, or is this…" }, { "start": 1388.91, "end": 1393.259, "text": "ICANN - MTS - A/V: somewhere else within ICANN organization as a preference, because those are two different" }, { "start": 1393.41, "end": 1407.459, "text": "ICANN - MTS - A/V: scenarios, one of which really gets to, if ICANN compliance believes it can't enforce the policy unless it has X, Y, and Z, that's a very different, different position than a preference from elsewhere in ICANN Org." }, { "start": 1408.81, "end": 1422.899, "text": "ICANN - MTS - A/V: Thank you, Brian. We're gonna go to Jeff and ask that question, where to give us the history lesson of where the language came from. Was it compliance or someplace else? In the meantime, while you listen to him, I'd like for you to multitask and consider the Reg variant of May." }, { "start": 1423.55, "end": 1426.68, "text": "ICANN - MTS - A/V: I'm so sorry, Peter. Sorry. Sorry, Jeff. Peter." }, { "start": 1427.4, "end": 1432.719, "text": "ICANN - MTS - A/V: That's alright, I can live with Jeff. Peter Eakin from ICANN Org. Just to clarify, ICANN Org" }, { "start": 1432.88, "end": 1438.879, "text": "ICANN - MTS - A/V: Regularly, indeed, it's standard that we submit public, comments on PDPs." }, { "start": 1439.37, "end": 1446.969, "text": "ICANN - MTS - A/V: And, this is the result of a cross-functional analysis that we undertake on the preliminary recommendations." }, { "start": 1447.11, "end": 1450.47, "text": "ICANN - MTS - A/V: And that is a group that comprises representation from" }, { "start": 1450.89, "end": 1453.84, "text": "ICANN - MTS - A/V: lots of parts of ICANN Org, including compliance." }, { "start": 1454.01, "end": 1457.39, "text": "ICANN - MTS - A/V: So, compliance were involved in this language." }, { "start": 1458.77, "end": 1465.7, "text": "ICANN - MTS - A/V: For us, we… It is… we proposed this as a refinement suggestion." }, { "start": 1466.43, "end": 1472.219, "text": "ICANN - MTS - A/V: Simply because we believe that the language as written" }, { "start": 1472.4, "end": 1478.91, "text": "ICANN - MTS - A/V: is potentially unclear as to exactly what, is intended." }, { "start": 1479.54, "end": 1482.719, "text": "ICANN - MTS - A/V: So we really just posed this to the group." }, { "start": 1483.54, "end": 1485.41, "text": "ICANN - MTS - A/V: To see, you know." }, { "start": 1485.72, "end": 1491.719, "text": "ICANN - MTS - A/V: if there was a way of potentially unpacking it a little bit, as I saw in one of the Zoom calls." }, { "start": 1491.85, "end": 1495.97, "text": "ICANN - MTS - A/V: comments that it was just much clearer of the intent. This is also with the." }, { "start": 1496.19, "end": 1499.2, "text": "ICANN - MTS - A/V: With really just thinking ahead to implementation." }, { "start": 1499.66, "end": 1506.31, "text": "ICANN - MTS - A/V: To sort of forestall, as someone says, a conversation that could happen in the IRT." }, { "start": 1506.53, "end": 1508.57, "text": "ICANN - MTS - A/V: potentially…" }, { "start": 1508.95, "end": 1516.649, "text": "ICANN - MTS - A/V: It's better, we think, to, where possible, address these sorts of, sort of, ambiguities now, if possible, and if the working group agree." }, { "start": 1519.73, "end": 1520.849, "text": "ICANN - MTS - A/V: Thank you, Peter." }, { "start": 1521.72, "end": 1522.78, "text": "ICANN - MTS - A/V: Okay." }, { "start": 1524.7, "end": 1526.46, "text": "ICANN - MTS - A/V: That's all the hands." }, { "start": 1526.98, "end": 1533.9, "text": "ICANN - MTS - A/V: Let's open a queue on the Reg variant. Who could… who has a problem with the Reg variant? Who could live with it?" }, { "start": 1536.63, "end": 1539.8, "text": "ICANN - MTS - A/V: It would be… we would switch out the…" }, { "start": 1540.54, "end": 1545.21, "text": "ICANN - MTS - A/V: You would say, may include, but is not limited to." }, { "start": 1546.98, "end": 1549.929, "text": "ICANN - MTS - A/V: And then we keep the rest of the straw person language." }, { "start": 1551.51, "end": 1552.29, "text": "ICANN - MTS - A/V: Mark." }, { "start": 1554.74, "end": 1559.06, "text": "ICANN - MTS - A/V: kind of like Mark Trachtenberg at the IPC, what I said in the chat, we just… I don't…" }, { "start": 1559.46, "end": 1569.78, "text": "ICANN - MTS - A/V: love Reddit's change, but we have to compromise here, and she's compromising by not loving the rest of the language, but being willing to live with that adjustment, so I… in the spirit of that." }, { "start": 1570.45, "end": 1571.519, "text": "ICANN - MTS - A/V: you know, I think I could…" }, { "start": 1571.92, "end": 1578.129, "text": "ICANN - MTS - A/V: Or the IPC could maybe do the same, and, you know, if she's willing to get on board with that, then maybe that's a way to make this happen." }, { "start": 1578.66, "end": 1583.75, "text": "ICANN - MTS - A/V: Thank you, Mark. Where everyone doesn't get exactly what they want, but we get closer to the… to what we think is best." }, { "start": 1585.61, "end": 1586.71, "text": "ICANN - MTS - A/V: Thank you, Mark." }, { "start": 1587.92, "end": 1590.8, "text": "ICANN - MTS - A/V: Any objections to the Reg variant?" }, { "start": 1593.33, "end": 1594.17, "text": "ICANN - MTS - A/V: Chris." }, { "start": 1595.62, "end": 1603.939, "text": "ICANN - MTS - A/V: It's not an objection as such, it's a clarification, and I apologize profusely for having my lawyer's hat firmly screwed onto my head right now." }, { "start": 1605.03, "end": 1608.94, "text": "ICANN - MTS - A/V: But irrespective of Reg's amendment, it seems to me that" }, { "start": 1609.34, "end": 1617.5, "text": "ICANN - MTS - A/V: The switch does make a difference because it says information the registrar is required to collect or maintain under its contractual obligations." }, { "start": 1617.88, "end": 1618.68, "text": "ICANN - MTS - A/V: 1." }, { "start": 1618.92, "end": 1625.0, "text": "ICANN - MTS - A/V: to information available through its technical systems and reasonably accessible. Now, what that means" }, { "start": 1625.25, "end": 1627.89, "text": "ICANN - MTS - A/V: Is that the information reasonably accessible." }, { "start": 1628.72, "end": 1636.079, "text": "ICANN - MTS - A/V: if you parse it correctly, only applies to information available through its technical systems. Now, that may not matter, I'm not a registrar." }, { "start": 1636.24, "end": 1650.91, "text": "ICANN - MTS - A/V: But it seems to me that having the information or where you say reasonably ordinarily at the beginning means it applies to everything. And as it's currently written, it only applies to information available through its technical systems. I have no idea if that makes any difference." }, { "start": 1651.4, "end": 1658.41, "text": "ICANN - MTS - A/V: But it's a point, I think, it is a point of difference in the text that needs to be clear for people to understand. Thanks." }, { "start": 1659.94, "end": 1661.03, "text": "ICANN - MTS - A/V: Thanks, Chris." }, { "start": 1661.13, "end": 1667.139, "text": "ICANN - MTS - A/V: The way I was reading it is that the first reasonably accessible in the black font." }, { "start": 1668.09, "end": 1672.569, "text": "ICANN - MTS - A/V: sort of takes care of that. We just use reasonably accessible again, which is" }, { "start": 1672.97, "end": 1676.649, "text": "ICANN - MTS - A/V: common in ICANN definitions, they tend to be a little bit circular." }, { "start": 1676.77, "end": 1681.489, "text": "ICANN - MTS - A/V: I don't think because we use it later… That may be true. …that thing becomes unreasonably accessible, yeah." }, { "start": 1681.98, "end": 1684.24, "text": "ICANN - MTS - A/V: So I think we're okay. I don't like it." }, { "start": 1684.41, "end": 1687.5, "text": "ICANN - MTS - A/V: But… Ching." }, { "start": 1688.29, "end": 1701.219, "text": "ICANN - MTS - A/V: Thank you, Paul. Ching from the BC. We have a short discussion, so the BC feels that the original test and the new text, pretty much, as Chris pointed out, is pretty much the same, except the reseller part, which, if…" }, { "start": 1701.41, "end": 1707.5, "text": "ICANN - MTS - A/V: If the group says, you know, the new text is better, we will actually support the new text." }, { "start": 1707.82, "end": 1708.54, "text": "ICANN - MTS - A/V: Thanks." }, { "start": 1709.01, "end": 1713.19, "text": "ICANN - MTS - A/V: ABC supports the Reg variant. Reg, do you support the Reg variant?" }, { "start": 1715.33, "end": 1716.21, "text": "Reg Levy – Tucows: I…" }, { "start": 1716.8, "end": 1726.16, "text": "Reg Levy – Tucows: I'm trying to make changes on the fly, and what I would really like to do is be able to type something into this so that I can read it, and… and that's not really possible right now." }, { "start": 1726.41, "end": 1740.21, "text": "Reg Levy – Tucows: Again, my preferred is what we had agreed to before, because every single piece that is in the new proposed definition from ICANN is something that we considered and did not agree to. So…" }, { "start": 1740.54, "end": 1745.76, "text": "Reg Levy – Tucows: I'm trying to figure out how to make it be something close to what it was." }, { "start": 1745.95, "end": 1756.2, "text": "Reg Levy – Tucows: And the maybe, but is not limited to, As… As Chris noted." }, { "start": 1757.2, "end": 1769.3, "text": "Reg Levy – Tucows: There is a presumption in this definition as it stands that information that is reasonably accessible is not included in" }, { "start": 1770.49, "end": 1786.759, "text": "Reg Levy – Tucows: information that we're required to collect or maintain, like, that those are two different sets, and I agree with that. So as long as we say it's one or the other, great. Because it should not be both. If something is not reasonably accessible, even the… wow, I almost said a vault, but…" }, { "start": 1787.09, "end": 1801.849, "text": "Reg Levy – Tucows: Even though it exists, if it's not reasonably accessible, it ought not be reasonable for us to look at it, or to use it when we're considering our ADC. And again, that is what we got to at the end." }, { "start": 1803.24, "end": 1820.599, "text": "Reg Levy – Tucows: And while it is interesting to note that ICANN staff thinks that all information that we are required to collect is necessarily reasonable, the way that it was written specifically said that the WG" }, { "start": 1820.74, "end": 1835.89, "text": "Reg Levy – Tucows: took that into consideration, and said that that wasn't true. And that gave us the opportunity to argue to ICANN compliance that something that we do have is not reasonably accessible." }, { "start": 1836.25, "end": 1844.24, "text": "Reg Levy – Tucows: And that we would argue with ICANN compliance about the reasonability of that specific piece of information, and it didn't have to go through" }, { "start": 1844.68, "end": 1846.18, "text": "Reg Levy – Tucows: This whole process." }, { "start": 1846.44, "end": 1850.27, "text": "Reg Levy – Tucows: And I'm trying to get us back to something close to that." }, { "start": 1851.13, "end": 1855.04, "text": "Reg Levy – Tucows: So I don't know, I guess, is the answer to whether or not I still agree with my proposal." }, { "start": 1856.71, "end": 1862.75, "text": "ICANN - MTS - A/V: Thank you, Reg. Okay, I'm asking for anybody else that wants to say something about this to get in behind Tomas." }, { "start": 1862.88, "end": 1866.67, "text": "ICANN - MTS - A/V: Because I'm going to draw a line under it there. Martina, go ahead." }, { "start": 1867.4, "end": 1876.09, "text": "ICANN - MTS - A/V: Thank you very much, Paul. I'm sorry to be the one more negative on Reg's proposal, but I we're not super super comfortable with May here." }, { "start": 1876.56, "end": 1886.16, "text": "ICANN - MTS - A/V: We would prefer the ease. And I will reiterate that I think for us it's important that both registrars and ICANN are comfortable with what does this mean?" }, { "start": 1886.46, "end": 1893.95, "text": "ICANN - MTS - A/V: But maybe there's some drafting that they can do together that respects the spirits of the original sentence, and we keep the ease?" }, { "start": 1894.28, "end": 1898.349, "text": "ICANN - MTS - A/V: Because I think the May would open a bit of a Pandora box on our side." }, { "start": 1900.69, "end": 1901.57, "text": "ICANN - MTS - A/V: Tomas." }, { "start": 1902.46, "end": 1905.63, "text": "Thomas Rickert: Thanks so much. Hi, everybody." }, { "start": 1906.11, "end": 1913.13, "text": "Thomas Rickert: I have a question. The way I read the original language… with, ordinarily." }, { "start": 1913.31, "end": 1925.27, "text": "Thomas Rickert: Would not require a contracted party to pull data from systems that might not be part of the production system." }, { "start": 1925.78, "end": 1927.919, "text": "Thomas Rickert: What do I mean by that?" }, { "start": 1928.08, "end": 1931.579, "text": "Thomas Rickert: I'm looking at this from a legal perspective, being a lawyer." }, { "start": 1931.77, "end": 1937.349, "text": "Thomas Rickert: But you know that let's say there are invoices that you need to keep for 10 years." }, { "start": 1937.77, "end": 1941.659, "text": "Thomas Rickert: But, the folks operating the abuse desk" }, { "start": 1942.03, "end": 1953.17, "text": "Thomas Rickert: may be blocked from access to that system, right? Because they don't need to see that data anymore, past a certain duration. So, what is the view of the…" }, { "start": 1953.75, "end": 1957.969, "text": "Thomas Rickert: Folks that, Better English speakers than me." }, { "start": 1958.55, "end": 1962.51, "text": "Thomas Rickert: I think the… The proposed language would require" }, { "start": 1962.88, "end": 1969.39, "text": "Thomas Rickert: A contracted party to pull whatever data they have, even from systems that they may not" }, { "start": 1969.68, "end": 1974.829, "text": "Thomas Rickert: Have access to, you know, like, the bookkeeping requirements." }, { "start": 1975.79, "end": 1981.209, "text": "Thomas Rickert: And if that were the case, then the question for the working group is, do we want contracted parties to" }, { "start": 1984.93, "end": 2001.499, "text": "Thomas Rickert: to tweak their processes counter to what GDPR would require them to do, and make data that can't ordinarily be part of a production system back to the production system. I hope that I'm making myself… Yeah, it's pretty early, so I'm not leaning one way or the other." }, { "start": 2001.65, "end": 2007.38, "text": "Thomas Rickert: Just raising that, because I'm a little bit at loss with, Proposed new language." }, { "start": 2008.69, "end": 2011.209, "text": "ICANN - MTS - A/V: Thanks Tomas. We have Marc and then Volker. Marc." }, { "start": 2012.46, "end": 2014.24, "text": "ICANN - MTS - A/V: Marc Trachtenberg of the IPC." }, { "start": 2015.94, "end": 2025.209, "text": "ICANN - MTS - A/V: I understand the argument that Reg wants to make to compliance about the things that aren't reasonably accessible because they're in different technical systems or something else, but I think that with her change, and actually even without it." }, { "start": 2026.9, "end": 2034.7, "text": "ICANN - MTS - A/V: And going back to the language without Reg's change, as Martina says, I still think that Reg and registrars have the ability to still make that argument to compliance." }, { "start": 2034.97, "end": 2038.18, "text": "ICANN - MTS - A/V: Compliance says you're not. You're not complying. You didn't do a reasonable investigation." }, { "start": 2038.75, "end": 2049.1, "text": "ICANN - MTS - A/V: It's like, well, these are the things that we could look at, but we didn't look at these because they're not accessible for this reason. And then compliance could decide whether that's reasonable. So I think that argument is not precluded by this language." }, { "start": 2049.25, "end": 2050.739, "text": "ICANN - MTS - A/V: With or without Regis Change." }, { "start": 2051.01, "end": 2053.569, "text": "ICANN - MTS - A/V: It's still an argument that can be made to compliance." }, { "start": 2053.739, "end": 2057.19, "text": "ICANN - MTS - A/V: Which, I think the compliance… Would be… would take into account." }, { "start": 2057.44, "end": 2061.619, "text": "ICANN - MTS - A/V: They're not trying to unnecessarily punish the registrars, they're just trying to enforce the contracts." }, { "start": 2063.62, "end": 2065.139, "text": "ICANN - MTS - A/V: Thanks, Mark Volker." }, { "start": 2066.08, "end": 2072.05, "text": "ICANN - MTS - A/V: Yes, and… Parker Greiman for the record, for the RRSG." }, { "start": 2072.35, "end": 2079.139, "text": "ICANN - MTS - A/V: We have discussed it during the working groups, but I think it bears just bringing it back for people to have it on the top of their minds." }, { "start": 2079.989, "end": 2096.94, "text": "ICANN - MTS - A/V: when we deal with an abuse complaint, this is not a matter where we take an abuse complaint, then ruminate on that for a day or two, then we look at the data that we may have available in all the databases, and spend days and days on each abuse report to make sure that we find all the data that we have available to it." }, { "start": 2097.51, "end": 2104.309, "text": "ICANN - MTS - A/V: And then we decide on that. Looking at an abuse complaint has to be done… doable in 5 to 10 minutes." }, { "start": 2104.44, "end": 2113.739, "text": "ICANN - MTS - A/V: That is the time that we have available to us to, action… to review, action, and, notify." }, { "start": 2114.01, "end": 2131.75, "text": "ICANN - MTS - A/V: that sounds like a little, because it is. However, that's the reality of how these reports have to be done, because of the volumes that we're receiving. If we are expected to look at non-production databases, reach out to resellers, what they… information they may have available, because that's in there as well." }, { "start": 2131.79, "end": 2137.91, "text": "ICANN - MTS - A/V: That, for example, that we outsource to them, because they own the customer relationships." }, { "start": 2138.02, "end": 2140.11, "text": "ICANN - MTS - A/V: And do all these extra steps." }, { "start": 2140.44, "end": 2145.0, "text": "ICANN - MTS - A/V: For every abuse complaint that we receive that might warrant an ADC," }, { "start": 2145.68, "end": 2155.7, "text": "ICANN - MTS - A/V: Do you want more abuse that we take care of less abuse? Is that the goal here? If that's the goal here, is that way we… if that is where we are, then that's what you can have, but…" }, { "start": 2155.92, "end": 2166.08, "text": "ICANN - MTS - A/V: I'm not sure that anyone will be satisfied with the result of that. The result should be a process that's workable, that's fast, expedient, and that produces results." }, { "start": 2166.69, "end": 2170.55, "text": "ICANN - MTS - A/V: If that's not the goal, then I'm not sure why we're here." }, { "start": 2172.31, "end": 2178.849, "text": "ICANN - MTS - A/V: Thanks, Volker. So… I said I would draw a line, after…" }, { "start": 2179.68, "end": 2182.52, "text": "ICANN - MTS - A/V: I forgot who it was." }, { "start": 2182.64, "end": 2184.689, "text": "ICANN - MTS - A/V: And we've had 3 more pop up." }, { "start": 2185.32, "end": 2192.78, "text": "ICANN - MTS - A/V: So, I'm gonna get criticized for this, because everybody will say I don't draw lines when I say I'll draw lines, but okay, we're almost done with the BDP." }, { "start": 2192.96, "end": 2198.889, "text": "ICANN - MTS - A/V: So, we're gonna hear from… we're gonna hear from Mark again, then Chris again, and then Yao." }, { "start": 2199.01, "end": 2203.71, "text": "ICANN - MTS - A/V: And then that'll be it, and then we'll have to decide what to do with this one. Mark, go ahead." }, { "start": 2206.14, "end": 2207.86, "text": "ICANN - MTS - A/V: Marc Trachtenberg for the IPC." }, { "start": 2209.47, "end": 2214.959, "text": "ICANN - MTS - A/V: I think the language that Fayo put in the chat is very helpful here, because it makes it extremely clear" }, { "start": 2215.17, "end": 2220.559, "text": "ICANN - MTS - A/V: that… A reasonable investigation does not require consideration of every category in every case." }, { "start": 2220.79, "end": 2236.34, "text": "ICANN - MTS - A/V: And so this language, like, creates the universe for what's available, what could be reasonable, but then it's also limited by this implementation guidance, which makes clear that the registrar does not have to consider every one of these pieces of data. So I think that is a very helpful limitation and ensures" }, { "start": 2236.42, "end": 2242.169, "text": "ICANN - MTS - A/V: that Reg and, you know, Volker and anyone else who wants to make the argument that something was not reasonably accessible, and that's why they didn't look at it." }, { "start": 2242.38, "end": 2243.659, "text": "ICANN - MTS - A/V: They're able to do that." }, { "start": 2244.09, "end": 2249.53, "text": "ICANN - MTS - A/V: It's just… The language makes clear that all… the other language includes, like, what is the universe of what" }, { "start": 2249.93, "end": 2253.86, "text": "ICANN - MTS - A/V: you know, What is reasonably accessible?" }, { "start": 2254.34, "end": 2258.49, "text": "ICANN - MTS - A/V: But again, you don't have to look at every single thing. That's up to the discretion of the registrar." }, { "start": 2259.85, "end": 2261.13, "text": "ICANN - MTS - A/V: Thanks, Mark. Chris?" }, { "start": 2262.11, "end": 2265.45, "text": "ICANN - MTS - A/V: Thank you, Paul, and I apologize for raising my hand again." }, { "start": 2265.92, "end": 2268.329, "text": "ICANN - MTS - A/V: I may be slightly confused, and if I am." }, { "start": 2268.57, "end": 2276.069, "text": "ICANN - MTS - A/V: I apologize again in advance. If I understand it correctly, the intent of this change is to clarify" }, { "start": 2276.33, "end": 2279.26, "text": "ICANN - MTS - A/V: What the original wording meant. Not to change it." }, { "start": 2280.15, "end": 2283.359, "text": "ICANN - MTS - A/V: So, not to change the meaning of it. And so…" }, { "start": 2283.63, "end": 2291.919, "text": "ICANN - MTS - A/V: Arguments about the substance aren't really relevant. The question is, does this language change What was said before." }, { "start": 2292.55, "end": 2310.849, "text": "ICANN - MTS - A/V: substantively, or is it merely a clarification? So, could I suggest that maybe the answer to… the way to deal with it might be to let the people who care about it think about it for a little while, consider the words properly, and maybe come… if it's at all possible, maybe come back to it?" }, { "start": 2311.13, "end": 2318.95, "text": "ICANN - MTS - A/V: Perhaps at the next session briefly to see whether or not they believe the wording means the same. 'Cause to ask, it's legal wording." }, { "start": 2319.11, "end": 2323.23, "text": "ICANN - MTS - A/V: as it's currently written. I suspect it may well have been written by a lawyer, I could be wrong." }, { "start": 2323.39, "end": 2330.169, "text": "ICANN - MTS - A/V: And therefore it may be helpful to let Volker and Reg and registrars look at it and see if, in fact." }, { "start": 2330.47, "end": 2336.089, "text": "ICANN - MTS - A/V: They think it makes… it is simply a clarification, or it does make a… it makes a substantive difference. Thanks." }, { "start": 2337.18, "end": 2343.109, "text": "ICANN - MTS - A/V: Thanks, Chris. The problem with kicking the can into the next session is we're not going to get done." }, { "start": 2343.47, "end": 2350.43, "text": "ICANN - MTS - A/V: Right? And so, I hate to be that guy, but everybody had this for several days, and if we…" }, { "start": 2350.68, "end": 2356.269, "text": "ICANN - MTS - A/V: start kicking the hard stuff into the next session. We're going to end up kicking half the issues out on Thursday." }, { "start": 2356.56, "end": 2359.51, "text": "ICANN - MTS - A/V: So, yeah." }, { "start": 2360.29, "end": 2366.989, "text": "ICANN - MTS - A/V: Yeah, thank you. This is Yao for NPOC. Yeah, I agree with you, we need to make a decision today about this." }, { "start": 2367.12, "end": 2372.12, "text": "ICANN - MTS - A/V: My concern is… Really, to…" }, { "start": 2372.41, "end": 2379.719, "text": "ICANN - MTS - A/V: try to understand why this, the agreed recommendation we already have for this addition is not." }, { "start": 2380.28, "end": 2391.619, "text": "ICANN - MTS - A/V: supportive of the compliant task that ICANN or ICANN compliant will do if we maintain the recommendation as it is initial without any addition." }, { "start": 2391.95, "end": 2404.29, "text": "ICANN - MTS - A/V: And even though with the… with the suggestion Reg made, which I'm not totally against, but I also think with the addition of wording, like resellers and other things, my…" }, { "start": 2404.6, "end": 2410.14, "text": "ICANN - MTS - A/V: We need to reconsider a role like, see what Other implication, this…" }, { "start": 2410.46, "end": 2422.589, "text": "ICANN - MTS - A/V: will imply, if we keep it like that. So, suggestion line here would be, why not keeping what we agreed on so far, and then the addition of the… for me, it's like a clarification." }, { "start": 2422.88, "end": 2426.989, "text": "ICANN - MTS - A/V: Then we put it into into the implementation guideline." }, { "start": 2427.29, "end": 2429.56, "text": "ICANN - MTS - A/V: So then we have a grinder. Okay." }, { "start": 2430.38, "end": 2431.349, "text": "ICANN - MTS - A/V: Thanks, y'all." }, { "start": 2432.46, "end": 2437.15, "text": "ICANN - MTS - A/V: Alright, so… That's a good… that's a good idea." }, { "start": 2440.0, "end": 2447.63, "text": "ICANN - MTS - A/V: They're, they're… you know, if we're going to change something that was a subject of significant compromise, and history will record that this was" }, { "start": 2447.94, "end": 2455.559, "text": "ICANN - MTS - A/V: a significant disagreement between the IPC and the registrars, and it was resolved through the compromise language that appears in black font." }, { "start": 2455.95, "end": 2462.659, "text": "ICANN - MTS - A/V: Folks, we need for that to be by wild acclaim, everybody claps and says we did a great job, right? So…" }, { "start": 2462.82, "end": 2471.149, "text": "ICANN - MTS - A/V: This will remain as it was. And we were gonna, you know, we have some implementation guidance to look at." }, { "start": 2471.26, "end": 2475.09, "text": "ICANN - MTS - A/V: There's an IRT ahead." }, { "start": 2475.21, "end": 2478.65, "text": "ICANN - MTS - A/V: There are advisories by compliance." }, { "start": 2478.79, "end": 2482.95, "text": "ICANN - MTS - A/V: So we're gonna have to just trust the universe to unfold." }, { "start": 2483.12, "end": 2484.89, "text": "ICANN - MTS - A/V: And we're moving on." }, { "start": 2485.99, "end": 2487.46, "text": "ICANN - MTS - A/V: All right?" }, { "start": 2488.06, "end": 2492.74, "text": "ICANN - MTS - A/V: And I know that I probably made some people unhappy, but… Okay." }, { "start": 2494.96, "end": 2497.339, "text": "ICANN - MTS - A/V: Let's go to the next item." }, { "start": 2501.5, "end": 2503.419, "text": "ICANN - MTS - A/V: Record comment 4?" }, { "start": 2504.47, "end": 2505.17, "text": "ICANN - MTS - A/V: Okay." }, { "start": 2509.02, "end": 2527.91, "text": "ICANN - MTS - A/V: Hi, everyone. So now we are seeing here, the main common clusters for Recommendation 4 and Implementation Guidance 4.1. There was one fairly editorial change that caused some confusion, the AND, OR, when we listed the non-exhaustive list." }, { "start": 2528.09, "end": 2535.97, "text": "ICANN - MTS - A/V: Furthermore, many commenters suggested… suggested, sorry, to expand the list of indicators." }, { "start": 2536.14, "end": 2547.74, "text": "ICANN - MTS - A/V: However, the working group noted that this is just a non-exhaustive list to take into consideration for various reasons, so we can provide some rationale or a clarification what the intent of this list is." }, { "start": 2547.9, "end": 2556.109, "text": "ICANN - MTS - A/V: is Furthermore, there were some comments on, why this seems too flexible, why is not one" }, { "start": 2556.14, "end": 2569.699, "text": "ICANN - MTS - A/V: category mandatory. Also, we note that the working group discussed this before, and there were very clear reasons why the working group wanted to keep the list as is, because not all indicators result in the same." }, { "start": 2570.63, "end": 2583.549, "text": "ICANN - MTS - A/V: or are connected to the same, so I think that is what the next two slides would want to clarify and just strengthen the working group rationale and intent with recommendation 4." }, { "start": 2583.66, "end": 2586.439, "text": "ICANN - MTS - A/V: So I hand over to Paul to introduce those." }, { "start": 2587.36, "end": 2596.659, "text": "ICANN - MTS - A/V: Thank you. There was a question in the chat, which I've just responded to from Jothan. That is correct. We are not adopting the red text, we are moving back to the black font text." }, { "start": 2598.61, "end": 2602.059, "text": "ICANN - MTS - A/V: Okay, I need the next slide. Here we go." }, { "start": 2605.49, "end": 2616.859, "text": "ICANN - MTS - A/V: So, here's the proposed update. Again, a straw person. This is just what leadership tried to do to incorporate public comment. It is not binding, and as we saw from the last" }, { "start": 2616.99, "end": 2621.86, "text": "ICANN - MTS - A/V: Rec. It is completely pushed back uponable. Is that a word pushed back uponable?" }, { "start": 2622.01, "end": 2634.72, "text": "ICANN - MTS - A/V: I just created a new phrase. Okay? So the proposed new language to determine whether association exists. A registrar must take into consideration reasonably accessible indicators." }, { "start": 2635.06, "end": 2640.42, "text": "ICANN - MTS - A/V: That are relevant under the circumstances, and likely to yield useful information." }, { "start": 2640.57, "end": 2644.0, "text": "ICANN - MTS - A/V: Such indicators may include, as applicable." }, { "start": 2644.15, "end": 2647.559, "text": "ICANN - MTS - A/V: Registered name holder or account-related information." }, { "start": 2647.85, "end": 2653.889, "text": "ICANN - MTS - A/V: technical indicators and indicators of coordinated activity or registration patterns." }, { "start": 2654.19, "end": 2665.219, "text": "ICANN - MTS - A/V: When determining association, the specific elements considered in any given ADC, even within a single registrar, may vary depending upon the particular circumstances." }, { "start": 2665.94, "end": 2673.0, "text": "ICANN - MTS - A/V: So, let us… I'm sorry. Oh, there's another slide. Okay, sorry. All that's Get to that." }, { "start": 2674.06, "end": 2677.489, "text": "ICANN - MTS - A/V: And then the idea is to add to the implementation guidance." }, { "start": 2677.79, "end": 2680.48, "text": "ICANN - MTS - A/V: After the current non-exhaustive list." }, { "start": 2681.9, "end": 2689.05, "text": "ICANN - MTS - A/V: These indicators are illustrative and non-exhaustive, and their evidentiary weight may vary depending on the circumstances." }, { "start": 2689.2, "end": 2699.37, "text": "ICANN - MTS - A/V: No single week or commonly shared infrastructure indicator necessarily establishes association or common control. In such… in such…" }, { "start": 2699.63, "end": 2702.109, "text": "ICANN - MTS - A/V: Apologies. In some circumstances." }, { "start": 2702.28, "end": 2713.14, "text": "ICANN - MTS - A/V: One sufficiently specific indicator may support a reasonable determination of association. In other circumstances, multiple indicators may need to be considered together, okay?" }, { "start": 2713.59, "end": 2719.03, "text": "ICANN - MTS - A/V: All right, let's, open… Q on this, can I hear from Reg?" }, { "start": 2721.23, "end": 2739.32, "text": "Reg Levy – Tucows: Reg Levy from the Registrar Stakeholder Group. Strong support! I love it! Can we go back to the other slide? I have a slight quibble. Grammatically, there should not be a comma before the second AND. It should either be a colon and no AND, or simply no comma. Otherwise, love it! It's great!" }, { "start": 2741.64, "end": 2742.939, "text": "ICANN - MTS - A/V: Death to the comma." }, { "start": 2744.2, "end": 2744.91, "text": "ICANN - MTS - A/V: All right." }, { "start": 2745.99, "end": 2749.77, "text": "ICANN - MTS - A/V: Anyone else have anything to say about this one?" }, { "start": 2752.69, "end": 2753.64, "text": "ICANN - MTS - A/V: Jothan." }, { "start": 2756.4, "end": 2761.389, "text": "ICANN - MTS - A/V: I… and… I'm, Jothan Frakes for the record, I'm here with my SAC hat on." }, { "start": 2761.56, "end": 2769.98, "text": "ICANN - MTS - A/V: Really principally, it might be the case that, there may be signals that are… A." }, { "start": 2770.32, "end": 2779.209, "text": "ICANN - MTS - A/V: Not relevant, as well. That could be, that may not be actually indicators that might, under other circumstances, show" }, { "start": 2779.74, "end": 2785.449, "text": "ICANN - MTS - A/V: association in other circumstances. So there's a… there's a larger fact pattern to look at on these." }, { "start": 2785.96, "end": 2786.76, "text": "ICANN - MTS - A/V: Thank you." }, { "start": 2788.89, "end": 2791.75, "text": "ICANN - MTS - A/V: Thanks, Jothan. Does that…" }, { "start": 2792.58, "end": 2796.3, "text": "ICANN - MTS - A/V: Do we need to consider a textual change for that, or is that a general comment?" }, { "start": 2796.55, "end": 2800.08, "text": "ICANN - MTS - A/V: I just take it as a general comment. I don't think that's additive. Thank you." }, { "start": 2800.31, "end": 2801.36, "text": "ICANN - MTS - A/V: Thank you." }, { "start": 2802.28, "end": 2805.59, "text": "ICANN - MTS - A/V: Any other hands? Anybody want to…" }, { "start": 2809.0, "end": 2811.39, "text": "ICANN - MTS - A/V: Anybody? Oh, Michaela, thank you." }, { "start": 2812.47, "end": 2822.329, "text": "ICANN - MTS - A/V: Hi, Michaela, for the record. I'm… maybe this is just my brain, but I'm having a little trouble with the sufficiently specific indicator." }, { "start": 2822.52, "end": 2837.26, "text": "ICANN - MTS - A/V: Like, that's not a criterion I recall us discussing, and that seems like that brings in significantly new language to consider, as an… I think that's just language I'm a little confused on. I don't know if we could provide some more clarity on that." }, { "start": 2837.52, "end": 2855.38, "text": "ICANN - MTS - A/V: similarly, again, might just be a little jet-lagged, but I'm a little confused as to how… okay, so no singular… no single week or commonly shared indicator, la la la. But then, in some cases, one is sufficiently specific. It just seems, like, slightly logically confusing, but…" }, { "start": 2855.71, "end": 2863.55, "text": "ICANN - MTS - A/V: again, if others… if it makes sense to others, that I'll defer to the group consensus, but I think I'm a little confused about the logic of" }, { "start": 2863.7, "end": 2867.12, "text": "ICANN - MTS - A/V: No singular one, but then sometimes one singular is enough." }, { "start": 2867.45, "end": 2869.58, "text": "ICANN - MTS - A/V: But maybe that's just the phrasing there." }, { "start": 2870.38, "end": 2876.46, "text": "ICANN - MTS - A/V: Thanks, Michaela. I'll try to explain what we try to do with this. And I actually think the problem is that we…" }, { "start": 2876.95, "end": 2888.69, "text": "ICANN - MTS - A/V: We put sufficiently, right? That word is sort of redundant with the other thing, because if it does support a reasonable determination of association, it was therefore sufficient, right?" }, { "start": 2888.98, "end": 2900.909, "text": "ICANN - MTS - A/V: And so the idea behind no single weak or commonly shared infrastructure indicator necessarily establishes association or common control. Think about that in terms of, like." }, { "start": 2901.14, "end": 2917.649, "text": "ICANN - MTS - A/V: DNS records, right? That, you know, if you… when you register your domain name, you sign up for your registrar's DNS, right? Well, my domain name for my law firm probably shares DNS records with, you know, a million other websites." }, { "start": 2917.82, "end": 2920.059, "text": "ICANN - MTS - A/V: And so it wouldn't…" }, { "start": 2920.26, "end": 2938.319, "text": "ICANN - MTS - A/V: follow that, you know, that would be an indication that I'm associated with those domain names, right? So, that's an example of a weak infrastructure. association. But in some circumstances, one… and I scratched sufficient… I don't… sufficiently, I don't like it." }, { "start": 2938.52, "end": 2947.729, "text": "ICANN - MTS - A/V: One… even though I… even though it's there. Okay, one specific indicator may support a reasonable determination of association. So, for example, if" }, { "start": 2948.01, "end": 2952.909, "text": "ICANN - MTS - A/V: There was a maliciously registered domain name." }, { "start": 2953.12, "end": 2957.869, "text": "ICANN - MTS - A/V: by Fred Flintstone, who actually, I think I had a UDRP against at one point in my career." }, { "start": 2958.03, "end": 2967.17, "text": "ICANN - MTS - A/V: And in that account is another maliciously registered domain name, also by Fred Flintstone. That would be an indication." }, { "start": 2967.31, "end": 2971.95, "text": "ICANN - MTS - A/V: That's… that, to me, would be sufficient, right? And it's only one" }, { "start": 2972.13, "end": 2980.22, "text": "ICANN - MTS - A/V: one thing. So what we were trying to do with capturing this language is to explain how the sliding scale works, right?" }, { "start": 2980.25, "end": 2995.539, "text": "ICANN - MTS - A/V: And this is, this is something that, you know, Nick and I are both lawyers, so we're comfortable with because we're used to it, and especially in trademark law, we're extra used to this, right? Because no one indicator of the nine factors controls, you know, it's, you know." }, { "start": 2995.54, "end": 3001.27, "text": "ICANN - MTS - A/V: Some can be weak, some can be strong. So that was the idea behind it, and it was actually meant to protect" }, { "start": 3001.83, "end": 3013.51, "text": "ICANN - MTS - A/V: Does that make sense? Instead of saying, oh, one info… oh, you have the same DNS because you're all reg… you're… you're all registered through Namecheap, well, then you're all guilty, right? We're trying to keep that from happening." }, { "start": 3015.73, "end": 3034.98, "text": "ICANN - MTS - A/V: Okay? Yeah, Michaela, sorry, go ahead. Yeah, Michaela, just responding to that, so maybe this is more grammatical than anything, because it sounds like, okay, so no singular a lot, unless in some circumstances there is… like, sometimes there are cases where it's sufficient, where it's one indicator, if I understood correctly, and I think the way it's…" }, { "start": 3035.01, "end": 3047.46, "text": "ICANN - MTS - A/V: phrase now. Again, I'm not a lawyer, I'm not… specifically not a trademark lawyer, so maybe this is just language I'm not following, but I do want to make sure that it is comprehensible, because right now it just, again, seems logically confusing." }, { "start": 3047.53, "end": 3052.53, "text": "ICANN - MTS - A/V: In some, it is sufficient, some… but not sometimes." }, { "start": 3052.8, "end": 3062.389, "text": "ICANN - MTS - A/V: So I think if we could maybe try to play around with that language, just to make it a bit clearer, that would be appreciated. But again, if others… if it is understandable to others." }, { "start": 3062.53, "end": 3070.469, "text": "ICANN - MTS - A/V: I'll defer my point, but I'm a bit confused still. Thanks. But I get the spirit of what you're trying to convey, just not the way it's framed now." }, { "start": 3073.34, "end": 3080.739, "text": "ICANN - MTS - A/V: Thanks, Michaela. I guess what I'm going to do is to hit that pickleball back into your court and say, come up with the language that will make you comfortable." }, { "start": 3081.03, "end": 3084.67, "text": "ICANN - MTS - A/V: And you can work on that while we talk to Reg Reg, go ahead." }, { "start": 3085.37, "end": 3099.86, "text": "Reg Levy – Tucows: Don't change it. Reg Levy from the… from Tucows and the Registrar Stakeholder Group. Michaela, I do understand where you're coming from, but this makes total sense to me. And in our registrar back channel, many others." }, { "start": 3100.06, "end": 3103.53, "text": "Reg Levy – Tucows: It's not just a single indicator." }, { "start": 3104.19, "end": 3106.239, "text": "Reg Levy – Tucows: It's a single week indicator." }, { "start": 3106.56, "end": 3110.809, "text": "Reg Levy – Tucows: Or it is a single, commonly shared infrastructure indicator." }, { "start": 3110.92, "end": 3112.29, "text": "Reg Levy – Tucows: Versus…" }, { "start": 3112.57, "end": 3123.15, "text": "Reg Levy – Tucows: a sufficiently specific indicator. So, Volker put some stuff in the chat, but again, this makes total sense to me, and I'm absolutely on board with it. I can't just say." }, { "start": 3123.73, "end": 3133.59, "text": "Reg Levy – Tucows: Well, it's using Cloudflare, so here's a million other domains with Cloudflare infrastructure, therefore there's no associated domains." }, { "start": 3133.86, "end": 3140.07, "text": "Reg Levy – Tucows: That doesn't constitute a sufficient review because it's a weak indicator." }, { "start": 3140.53, "end": 3149.9, "text": "Reg Levy – Tucows: What I have to do is look and see, oh, this is registered by Fred Flintstone. I've got 4 other remains registered by Fred Flintstone's." }, { "start": 3150.06, "end": 3153.3, "text": "Reg Levy – Tucows: For some reason, that's a tongue twister for me." }, { "start": 3153.44, "end": 3157.23, "text": "Reg Levy – Tucows: I've got 4 other domains registered by this person." }, { "start": 3157.25, "end": 3176.619, "text": "Reg Levy – Tucows: So that is a sufficiently specific indicator. And… and it's going to be up to me to justify to ICANN which ones I used, and which… and whether or not they are considered weak or sufficiently specific. So I do understand where you're coming from, but I strongly…" }, { "start": 3176.62, "end": 3180.0, "text": "Reg Levy – Tucows: Hope that I've explained it well so that there are not changes." }, { "start": 3181.79, "end": 3182.689, "text": "ICANN - MTS - A/V: Thanks Reg." }, { "start": 3183.31, "end": 3184.11, "text": "ICANN - MTS - A/V: Mark?" }, { "start": 3187.02, "end": 3188.72, "text": "ICANN - MTS - A/V: or Trachtenberg for the IPC." }, { "start": 3188.99, "end": 3194.879, "text": "ICANN - MTS - A/V: I'm generally… I think we're generally okay with all this language. I understand all the points raised, I agree with" }, { "start": 3195.01, "end": 3198.099, "text": "ICANN - MTS - A/V: Michaela's point about sufficiently specific." }, { "start": 3198.29, "end": 3206.219, "text": "ICANN - MTS - A/V: I also understand and agree with what Reg is saying. I think maybe the solution to make it logically consistent is to replace sufficiently specific with strong." }, { "start": 3206.79, "end": 3218.099, "text": "ICANN - MTS - A/V: Right, because you say, no single weak or commonly shared infrastructure indicator necessarily establishes association or common control, but in some circumstances, one strong, which is the opposite of the weak." }, { "start": 3218.45, "end": 3226.889, "text": "ICANN - MTS - A/V: makes it logically consistent, and I think accomplishes the concerns that were raised by Reg and Michaela, and I think gets us to where we need to be, hopefully, if people are okay with that." }, { "start": 3227.17, "end": 3228.78, "text": "ICANN - MTS - A/V: Maybe Reg could respond?" }, { "start": 3229.78, "end": 3234.169, "text": "ICANN - MTS - A/V: Thanks, Mark. Well, Michaela was next, but hopefully Reg can respond. Michaela?" }, { "start": 3235.16, "end": 3253.139, "text": "ICANN - MTS - A/V: I mean, I think from my side, I would have to triple check with the NCSG, but I think, to me, that sounds fine. I think that was the… I was confused about the comparison, single week versus sufficiently specific. So, to me, Mark, that's a great solution from my view, but I'll just triple check quickly and come back in the chat on that. Thanks." }, { "start": 3254.4, "end": 3260.729, "text": "ICANN - MTS - A/V: Thank you, Michaela, and remember, Nick and I are not married to this text, we were just trying, so no one's hurting our feelings by changing" }, { "start": 3261.37, "end": 3263.53, "text": "ICANN - MTS - A/V: All right. Volker." }, { "start": 3264.74, "end": 3273.43, "text": "ICANN - MTS - A/V: Thank you, Volker Greimann for the RRSG. I think this is necessary because it also matches our realities in how we deal with these things." }, { "start": 3273.55, "end": 3275.57, "text": "ICANN - MTS - A/V: If…" }, { "start": 3275.71, "end": 3284.359, "text": "ICANN - MTS - A/V: We were nailed down to, always using the same indicators the same way, then we might be forced to," }, { "start": 3284.85, "end": 3288.089, "text": "ICANN - MTS - A/V: have bad decision making in the process." }, { "start": 3288.51, "end": 3300.749, "text": "ICANN - MTS - A/V: As an example, if we find certainly sequentially generated domains associated with a certain type of abuse, and can reasonably determine that they're all linked because of their naming conventions." }, { "start": 3300.82, "end": 3316.819, "text": "ICANN - MTS - A/V: That doesn't mean that we have to treat all sequentially named domains that have been generated in the same manner by an algorithm, for example, the same way, because if we cannot link all of them to that kind of abuse, or they're used differently, then that might not be an indicator of abuse." }, { "start": 3316.9, "end": 3322.079, "text": "ICANN - MTS - A/V: We must be able to treat similar." }, { "start": 3322.22, "end": 3329.449, "text": "ICANN - MTS - A/V: topics differently, depending on the circumstances, and therefore certain circumstances that make us do something may not make us do something. In another case." }, { "start": 3330.76, "end": 3331.969, "text": "ICANN - MTS - A/V: Thanks, Volker." }, { "start": 3334.54, "end": 3338.96, "text": "ICANN - MTS - A/V: from my point of view, correct, right? We are trying to take the non-robotic" }, { "start": 3339.84, "end": 3343.78, "text": "ICANN - MTS - A/V: approach, right? We want humans looking at this and balancing factors." }, { "start": 3344.6, "end": 3345.36, "text": "ICANN - MTS - A/V: Rod?" }, { "start": 3346.63, "end": 3349.18, "text": "ICANN - MTS - A/V: Yeah, Rod Rasmussen of the SSAC." }, { "start": 3351.61, "end": 3359.979, "text": "ICANN - MTS - A/V: not on the topic that we've been talking about clarifying the language here, but I want to make sure to get in, since we're talking about the implementation guidance for 4." }, { "start": 3360.21, "end": 3365.65, "text": "ICANN - MTS - A/V: I wanted to point out that the SSAC has published SSAC 1, or SAC 135." }, { "start": 3366.21, "end": 3376.159, "text": "ICANN - MTS - A/V: That was… but that was noticed. It was… so we didn't have direct input on the particular language in the… in the worksheet, but we did publish 135." }, { "start": 3376.31, "end": 3386.439, "text": "ICANN - MTS - A/V: That has been noted by others as well. In that SSAC document, we have a fairly… Comprehensive…" }, { "start": 3386.6, "end": 3393.23, "text": "ICANN - MTS - A/V: Analysis of different indicators, etc, that can be used, and how to combine them, etc." }, { "start": 3393.46, "end": 3397.779, "text": "ICANN - MTS - A/V: And I would also note that several of the other public comments" }, { "start": 3398.01, "end": 3410.53, "text": "ICANN - MTS - A/V: got into some of these areas that I think were quite useful in many of them. Some approaches that were, unique that, were not covered by the SSAC document as well." }, { "start": 3410.7, "end": 3419.1, "text": "ICANN - MTS - A/V: I bring this up because I think that we have a list in the implementation guidance right now. I know it's non-exhaustive." }, { "start": 3419.42, "end": 3428.1, "text": "ICANN - MTS - A/V: It's also non-authoritative, and we now may have some authoritative resources we can point to, such as the SAC 135 document." }, { "start": 3428.23, "end": 3430.379, "text": "ICANN - MTS - A/V: That might be worth adding." }, { "start": 3430.56, "end": 3436.38, "text": "ICANN - MTS - A/V: A bit here to look for implementation guidance, to look towards authoritative" }, { "start": 3436.5, "end": 3443.19, "text": "ICANN - MTS - A/V: work in this topic area, and SAC 135 might be one of those to add. Thanks." }, { "start": 3445.43, "end": 3447.36, "text": "ICANN - MTS - A/V: Thanks, Rod. Chris?" }, { "start": 3448.41, "end": 3467.97, "text": "ICANN - MTS - A/V: Thank you, Paul. Just in an attempt to clear up the misunderstandings on the wording or maybe make it a bit clearer. Part of the issue I think is that in the second sentence you say no single weak or commonly shared infrastructure indicator. I assume that in the next sentence where it says sufficiently specific indicator that you also mean infrastructure indicator, right? So that's the same thing." }, { "start": 3469.61, "end": 3488.399, "text": "ICANN - MTS - A/V: Because you've referred to one sentence as indicator and another sentence infrastructure indicator. So I'm assuming they are intended to be the same thing. That's my… that's the first point. Second point is that in the second sentence, it doesn't actually describe the infrastructure indicator in any way, and I know that there's been use of the word strong has been… has been brought up, but it seems to me" }, { "start": 3488.58, "end": 3490.28, "text": "ICANN - MTS - A/V: That if we simply said." }, { "start": 3490.49, "end": 3497.17, "text": "ICANN - MTS - A/V: In some circumstances, one sufficiently specific infrastructure indicator may support a reasonable determination of association." }, { "start": 3497.4, "end": 3503.469, "text": "ICANN - MTS - A/V: In other circumstances, For example, where the indicator is weak." }, { "start": 3504.54, "end": 3518.279, "text": "ICANN - MTS - A/V: multiple indicators may need to be considered together. In other words, string it, put it the other way around, make the clear statement about it is possible for it to be… for one indicator to be enough, but there are circumstances in which one indicator may not be enough, which includes where it's weak." }, { "start": 3520.01, "end": 3525.019, "text": "ICANN - MTS - A/V: Thanks, Chris. I think that's significantly different than what we were trying to accomplish. We were not trying to" }, { "start": 3525.37, "end": 3533.069, "text": "ICANN - MTS - A/V: to limit the strong indicators to just infrastructure indicators, right? So the Fred Flintstone idea? Yeah." }, { "start": 3533.25, "end": 3542.04, "text": "ICANN - MTS - A/V: So, but Chris, go ahead. Well, no, that's fine. If I've misunderstood, then I'm happy that it's not clear because I misunderstood it." }, { "start": 3544.41, "end": 3550.369, "text": "ICANN - MTS - A/V: We're trying to call out the weakness of infrastructure indicators because they show up as a commonality." }, { "start": 3550.76, "end": 3557.41, "text": "ICANN - MTS - A/V: As opposed to a very specific, or group of specific Or strong, under the…" }, { "start": 3557.66, "end": 3562.419, "text": "ICANN - MTS - A/V: Mark variant. Strong indicators, like Fred Flintstone." }, { "start": 3562.91, "end": 3565.989, "text": "ICANN - MTS - A/V: Showing up as the registrant, like, for a handful." }, { "start": 3567.34, "end": 3568.17, "text": "ICANN - MTS - A/V: Ching." }, { "start": 3568.95, "end": 3582.37, "text": "ICANN - MTS - A/V: Thank you, Paul. Ching from the BC. So, the more I read it, the term of… the term of evidentiary weight start to pop up more. So I actually put my question there, but I'd like to… just to clarify." }, { "start": 3582.37, "end": 3593.52, "text": "ICANN - MTS - A/V: So the example I'm giving now is, for example, there's five domains under one RNH, right? But only three resolved, right?" }, { "start": 3593.83, "end": 3608.289, "text": "ICANN - MTS - A/V: So two is not resolved. So three sharing you know one IP right. So in this text. So we're saying if registrar A has this thing this thing happening. So registrar B has the same thing happening." }, { "start": 3608.43, "end": 3612.779, "text": "ICANN - MTS - A/V: So that means that we will be… this will be acceptable." }, { "start": 3613.12, "end": 3629.72, "text": "ICANN - MTS - A/V: for ICANN that the ADC for Registrar A, for example, the end result is 5, and the Registrar B, the same scenario, but in Registrar B, they can only do, 3, to group 3 names, in one ADC group." }, { "start": 3630.04, "end": 3637.04, "text": "ICANN - MTS - A/V: Does that mean that we are okay with this type of You know, evidentiary weight." }, { "start": 3638.07, "end": 3640.279, "text": "ICANN - MTS - A/V: Just a question, to put it out there." }, { "start": 3641.46, "end": 3656.64, "text": "ICANN - MTS - A/V: So, if I'm understanding the question, I think that answer, without the specific example, I think that answer is yes, right? Like, we want registrars thinking for themselves, right? So, because if we build out a very prescriptive policy." }, { "start": 3656.66, "end": 3665.469, "text": "ICANN - MTS - A/V: it ages out as soon as we leave the room, because the bad guys thought of something else, right? Can I… yeah. So I'd just like to make sure the group understands this, so…" }, { "start": 3665.51, "end": 3670.31, "text": "ICANN - MTS - A/V: Even the scenario is the same. Once again, 5 names." }, { "start": 3670.6, "end": 3673.03, "text": "ICANN - MTS - A/V: under different, ARNETCH" }, { "start": 3673.37, "end": 3686.179, "text": "ICANN - MTS - A/V: Three IP… three share one IP, the other registrar… I mean, the other RNH does the same, but the groove is fine that the end result from registrar A to registrar B could be different." }, { "start": 3691.71, "end": 3693.19, "text": "ICANN - MTS - A/V: Okay, thanks, Ching." }, { "start": 3693.38, "end": 3695.21, "text": "ICANN - MTS - A/V: Yeah, it could be." }, { "start": 3699.04, "end": 3704.429, "text": "ICANN - MTS - A/V: And the only way to change that is to have a centralized whatever, and that's not what we did here." }, { "start": 3705.74, "end": 3709.82, "text": "ICANN - MTS - A/V: For good reasons. Not the least of which is competition law." }, { "start": 3710.48, "end": 3714.889, "text": "ICANN - MTS - A/V: Okay. Any other comments on this?" }, { "start": 3717.25, "end": 3718.299, "text": "ICANN - MTS - A/V: Michaela, go ahead." }, { "start": 3718.96, "end": 3725.339, "text": "ICANN - MTS - A/V: Thanks, Michaela, for the record. I… I don't want to throw a wrench into this, but I think the NCSG is still…" }, { "start": 3725.45, "end": 3742.219, "text": "ICANN - MTS - A/V: confused about this language, and I promise it's not just me and my jet lag. So what we wanted to propose, perhaps to make it a bit clearer and easier, is we really like that first sentence. So these indicators are all the way to depending on the circumstances." }, { "start": 3742.3, "end": 3746.789, "text": "ICANN - MTS - A/V: And we feel like that is more than sufficient, and we also have in…" }, { "start": 3746.88, "end": 3757.579, "text": "ICANN - MTS - A/V: the… in the rationale for 1 through 4, that no single data point will be determinative in all cases. So, from the NCSG's point of view." }, { "start": 3757.73, "end": 3770.82, "text": "ICANN - MTS - A/V: I think we've already covered the fact that no singular one is a sufficient indicator, and I think it's pretty clear also that given the evidentiary weight may vary, and, like, the… just that first sentence should be sufficient" }, { "start": 3770.93, "end": 3773.999, "text": "ICANN - MTS - A/V: To cover everything else that's currently in red." }, { "start": 3774.16, "end": 3783.789, "text": "ICANN - MTS - A/V: That's our view, and happy to hear what others think about that proposal. So striking everything after that first sentence, but still adding that first sentence. Thanks." }, { "start": 3785.26, "end": 3787.639, "text": "ICANN - MTS - A/V: Thanks, Michaela. Martina." }, { "start": 3789.38, "end": 3800.49, "text": "ICANN - MTS - A/V: I hear Michaela and I appreciate the suggestion and of course we can consider, but I do understand from reviewing all the comments indeed that there were people a bit confused about all this." }, { "start": 3800.82, "end": 3816.81, "text": "ICANN - MTS - A/V: And I also appreciate that the Reg and Volker seem happy with this language because it does seem to reflect an operational reality, which is that if you have a very weak indicators, you need more to connect the assessment. If you have a very strong one, maybe that's sufficient." }, { "start": 3817.18, "end": 3829.48, "text": "ICANN - MTS - A/V: in terms of clarification, and especially because people have expressed this need. I'm not sure we would need to delete everything. And I I think Reg's explanation was quite clear. So I I don't know." }, { "start": 3829.68, "end": 3845.709, "text": "ICANN - MTS - A/V: how we could do to make it better, but striking it all together, I mean, we can consider, but I think there is a value in having these examples. Maybe you can take it up with the registrars and see if there is any language that would make it clear from your perspective." }, { "start": 3846.05, "end": 3852.08, "text": "ICANN - MTS - A/V: which would maintain the examples, which I think were useful for the community. But it's just a suggestion." }, { "start": 3854.43, "end": 3855.679, "text": "ICANN - MTS - A/V: Thank you, Martina." }, { "start": 3857.19, "end": 3862.69, "text": "ICANN - MTS - A/V: All right, we have Mark. Anybody that wants to speak on this should get behind Mark, and…" }, { "start": 3862.81, "end": 3867.06, "text": "ICANN - MTS - A/V: Please don't jump in again and make me… you know." }, { "start": 3867.39, "end": 3868.22, "text": "ICANN - MTS - A/V: Ruth." }, { "start": 3868.87, "end": 3876.21, "text": "ICANN - MTS - A/V: make me have to, you know, extend the queue when I said I wouldn't. Otherwise, y'all are not gonna believe me. Mark, go ahead." }, { "start": 3877.46, "end": 3879.25, "text": "ICANN - MTS - A/V: Mark Trachtenberg with the IPC." }, { "start": 3880.39, "end": 3882.819, "text": "ICANN - MTS - A/V: I mean, I think I or we are okay with" }, { "start": 3883.22, "end": 3890.21, "text": "ICANN - MTS - A/V: either Martina's suggestion of striking all that other language, but I also see the value of having the examples in there, which is fine, too. I just…" }, { "start": 3890.84, "end": 3894.54, "text": "ICANN - MTS - A/V: Don't love specific, sufficiently specific. I think that" }, { "start": 3894.68, "end": 3900.779, "text": "ICANN - MTS - A/V: It's like you could say that you know the the name servers are sufficiently specific. They are. They're specific. It's one thing, I think." }, { "start": 3901.01, "end": 3906.95, "text": "ICANN - MTS - A/V: Personally, strong seems to capture it better. I understand Reggie objects to it. I'm not really sure I understand the objection, but…" }, { "start": 3907.86, "end": 3918.4, "text": "ICANN - MTS - A/V: So, I'm good with just the first sentence, or the whole sentence, but just doing something that's sufficiently specific, and if strong's not good, maybe a different word could be picked to kind of capture what I think we all… everyone seems to agree on the concept." }, { "start": 3918.6, "end": 3923.449, "text": "ICANN - MTS - A/V: Right? I don't think anyone seems to disagree, and everyone's trying to achieve the same thing. Maybe we could just…" }, { "start": 3924.06, "end": 3930.98, "text": "ICANN - MTS - A/V: Find a different word, or… Make people happy that we're… Saying what we mean." }, { "start": 3934.03, "end": 3937.419, "text": "ICANN - MTS - A/V: Thank you, Mark. Okay. I don't see any other hands." }, { "start": 3938.82, "end": 3944.739, "text": "ICANN - MTS - A/V: Trying to balance what I've heard, it sounds like…" }, { "start": 3945.48, "end": 3953.139, "text": "ICANN - MTS - A/V: Most of the people in the room are okay with this text, even if we don't change specific to strong." }, { "start": 3953.51, "end": 3955.729, "text": "ICANN - MTS - A/V: I do think it conveys meaning." }, { "start": 3956.11, "end": 3962.679, "text": "ICANN - MTS - A/V: And, we do have the NCSG wanting to strike the last two, but on the other hand." }, { "start": 3963.07, "end": 3967.27, "text": "ICANN - MTS - A/V: This implementation guidance is to registrars, and they're happy with it." }, { "start": 3967.83, "end": 3972.66, "text": "ICANN - MTS - A/V: And… Help that it, you know, they think it helps explain." }, { "start": 3973.14, "end": 3981.119, "text": "ICANN - MTS - A/V: So… I think, you know, we may fiddle with the text a little bit and bring it back to you guys in the next reading, but…" }, { "start": 3981.29, "end": 3983.589, "text": "ICANN - MTS - A/V: I think the concepts are going to stay." }, { "start": 3985.49, "end": 3986.16, "text": "ICANN - MTS - A/V: All right." }, { "start": 3987.11, "end": 3990.37, "text": "ICANN - MTS - A/V: Let us… Is that it?" }, { "start": 3991.55, "end": 3992.52, "text": "ICANN - MTS - A/V: Okay." }, { "start": 3993.61, "end": 3998.769, "text": "ICANN - MTS - A/V: All right. Is there anybody around the table or in the room that" }, { "start": 3999.63, "end": 4004.519, "text": "ICANN - MTS - A/V: Believes they did not get a chance to say anything they would like to say. As before." }, { "start": 4004.73, "end": 4011.739, "text": "ICANN - MTS - A/V: This doesn't mean that you'll get your way, but if you've not had a chance to say it, let's hear it, and maybe you will get your way. Who knows?" }, { "start": 4012.18, "end": 4015.61, "text": "ICANN - MTS - A/V: Anybody did not feel heard." }, { "start": 4019.77, "end": 4020.61, "text": "ICANN - MTS - A/V: Okay." }, { "start": 4022.73, "end": 4029.629, "text": "ICANN - MTS - A/V: Great. Well, once again, guys, good job. And, tomorrow's our session." }, { "start": 4030.03, "end": 4033.94, "text": "ICANN - MTS - A/V: Sunday morning at 1315." }, { "start": 4034.21, "end": 4038.07, "text": "ICANN - MTS - A/V: And in the GNSO Council Room right here." }, { "start": 4038.27, "end": 4044.29, "text": "ICANN - MTS - A/V: Everybody have a lovely time. I hope you get a few minutes to yourselves outside. It is beautiful." }, { "start": 4044.45, "end": 4045.499, "text": "ICANN - MTS - A/V: Thanks very much." }, { "start": 4048.29, "end": 4049.98, "text": "ICANN - MTS - A/V: And you can end the recording." } ], "text": "ICANN - MTS - A/V: Hello, and welcome to the DNS Abuse Mitigation PDP-1 Working Group Session 2 of 4. Please note that this session is being recorded and is governed by the ICANN Expected Standards of Behavior, the ICANN Community Anti-Harassment Policy, and the ICANN Community Participant Code of Conduct Concerning Statements of Interest.\nICANN - MTS - A/V: Please observe the guidelines to participate in this session. I will also post them in the chat for your reference. If you wish to speak, please raise your hand in Zoom or otherwise as directed. When speaking, please state your name for the record and speak clearly and at a moderate pace. With that, I'll hand the floor over to Paul McGrady. Please begin.\nICANN - MTS - A/V: Thank you, Terry. Welcome, everyone, to Session 2.\nICANN - MTS - A/V: of PDP1?\nICANN - MTS - A/V: We retained part of our crowd. How about that? We must have been very enthralling.\nICANN - MTS - A/V: We are going to be going through\nICANN - MTS - A/V: Recs 3 and 4, along with implementation guidance.\nICANN - MTS - A/V: 3.1 and 4.1 In this session, so… Let's get started.\nICANN - MTS - A/V: Bam.\nICANN - MTS - A/V: Hi, everyone, welcome back. As noted by Paul, as you see on the screen, the main comments received on Recommendation 3 that leadership thought\nICANN - MTS - A/V: could be implemented, considered in the language update, or, clarify what reasonably accessible information encompass in more specificity. We know that the group talked about this\nICANN - MTS - A/V: in the past, and it was quite strong compromise. However, I think there might be some changes justified to just explain the notion a bit better.\nICANN - MTS - A/V: Similarly, another cluster of public comment noted clarity or clarify reseller held information, registrar responsibility. So in the following slide, Paul will introduce how\nICANN - MTS - A/V: That could look like, in terms of language, we hope.\nICANN - MTS - A/V: that would address it. Back to Paul.\nICANN - MTS - A/V: Thank you. Fail. Okay.\nICANN - MTS - A/V: This is a proposed, language update to Rec 3, based upon, as you guys saw.\nICANN - MTS - A/V: Comments from lots of people saying we need to do some clarification here.\nICANN - MTS - A/V: It's considered a substantive Comment, or reason… so let's jump into it.\nICANN - MTS - A/V: The updated REC proposal I'll read it.\nICANN - MTS - A/V: A reasonable investigation by a registrar must consist of reviewing information reasonably accessible to the registrar in the normal course of its operations to determine whether associated domain names are being used for DNS abuse.\nICANN - MTS - A/V: As defined in 3.18.1 of the RAA.\nICANN - MTS - A/V: For the purposes of this recommendation, information reasonably accessible to the Registrar includes, but is not limited to, and here's the change.\nICANN - MTS - A/V: Information the Registrar is required to collect or maintain.\nICANN - MTS - A/V: Under its contractual obligations, Information available through its technical systems.\nICANN - MTS - A/V: and reasonably accessible to it directly or through resellers and information and records contained in abuse reports it receives.\nICANN - MTS - A/V: So, that's the proposed change. We're going to open a queue on this. Reg, please go ahead.\nReg Levy – Tucows: Thank you. Reg Levy from the Registrars and 2CAS.\nReg Levy – Tucows: I feel like we went over this many, many, many, many times and moved away from this, so it's kind of frustrating to see it back again.\nReg Levy – Tucows: Umm.\nReg Levy – Tucows: Yeah.\nReg Levy – Tucows: That's where I am.\nICANN - MTS - A/V: Thanks, Reg.\nICANN - MTS - A/V: And remember, this is just a straw person. If nobody wants to make any changes, we don't have to make any changes.\nICANN - MTS - A/V: Mark Trachtenberg for the IPC.\nICANN - MTS - A/V: This language looks good.\nICANN - MTS - A/V: to me, and I think would be acceptable to the IPC. I take Reg's point about how this was discussed.\nICANN - MTS - A/V: A lot.\nICANN - MTS - A/V: During the working group sessions, and it was, but there's a reason we have public comment, which is to solicit feedback from everyone. I mean, we have people that are representative of the different communities, but not everyone participates in the actual discussions and has access to everything, and so that's why we put it out for public comment. And there was substantial public comment on this issue.\nICANN - MTS - A/V: you know, raise some of these points that also were raised during our discussion. So, I think that the public comments show that there is a lot of interest in this, and that this was a hole, and that maybe here, the group didn't get it right.\nICANN - MTS - A/V: Thank you, Mark Volker.\nICANN - MTS - A/V: Yeah, Volker Kleiman, RRSG.\nICANN - MTS - A/V: I share a registered position that.\nICANN - MTS - A/V: We have been over this time and again, and really, this seems like a second bite of the apple by those that didn't get what they wanted originally. I also seem to recall, when I looked at the chart of support of the original recommendations, that the original recommendations had very high levels of support, and there was\nICANN - MTS - A/V: a significantly lower amount of people that want to change and had significant issues with that, so I would see this as a minor position, and\nICANN - MTS - A/V: The majority seems to be, of the commenters as well, and of the people that previously decided on the language that we had before, and that that language that we had before was the way to go, and the ideal solution. So I would.\nICANN - MTS - A/V: say that if this was something that was basically proposed by a majority of the commenters, then we should probably consider this. But if it's only a minority, then.\nICANN - MTS - A/V: Yeah, we've been over it.\nICANN - MTS - A/V: Thank you. Volker.\nICANN - MTS - A/V: And just to, Bring in some facts to support the\nICANN - MTS - A/V: concerns that we've been over it, because I'm not trying to put my thumb on the scale, but we're not… for those in the room that maybe weren't on all the working group calls, we did talk about this.\nICANN - MTS - A/V: On April 13th, May 4th.\nICANN - MTS - A/V: At ICANN 86 in sessions 1 and 2.\nICANN - MTS - A/V: ICANN 86 is sessions 3 and 4. We talked about it again on the 22nd of June.\nICANN - MTS - A/V: July 13th and August 3rd. So we have talked about this quite a bit.\nICANN - MTS - A/V: So, I… Again, the language that we have out here is just a…\nICANN - MTS - A/V: Straw person, in an attempt to…\nICANN - MTS - A/V: respond to the public comment. And\nICANN - MTS - A/V: So far, we've got some support for, others saying we've… without…\nICANN - MTS - A/V: necessarily saying there's anything wrong with the new language, just saying that, you know, we've been over it. Sounds like a second bite at the apple.\nICANN - MTS - A/V: We're gonna go to Martina, and go ahead.\nICANN - MTS - A/V: Thank you very much, Paul Martina, representing the GAC for the records. I mean, I think as the GAC, we were fine and accepted the previous language, but this specific comment comes from ICANN Org.\nICANN - MTS - A/V: So that puts me in a very uncomfortable chair, because if ICANNORC tells me that I should be worried about this language, then I'm double guessing myself, of course, and I would like to hear from the registrars\nICANN - MTS - A/V: Because we have trusted ICANN Org's judgment on a number of occasions, so maybe ICANN can explain why the comment came through, and the register can develop on,\nICANN - MTS - A/V: What's their interpretation of this concern from Eigenorg?\nICANN - MTS - A/V: Thanks, Martina. We have a representative of ICANN Org, and since we've used their name, why don't we ask them why they've asked for this change, what the enhancement is?\nICANN - MTS - A/V: Sure, Peter Rieken ICANN Org. So, I just want to clarify, this is a drafting clarification.\nICANN - MTS - A/V: So, we're not seeking to change the standard of a reasonably accessible information, or tell registers how to conduct.\nICANN - MTS - A/V: Their investigations, but to us, The, sort of, the current language of\nICANN - MTS - A/V: Contractual obligations, technical systems, research reports.\nICANN - MTS - A/V: Was… wasn't precise, it wasn't particularly clear.\nICANN - MTS - A/V: What that meant. So, we wanted to clarify that our understanding, right, was that that covers information that registrars are required to collect.\nICANN - MTS - A/V: through their own systems, or resellers, and information about the abuse reports that they received. So the aim of this was to make the scope of the standard clearer, without changing what registers are required to do, or prescribe how they do it.\nICANN - MTS - A/V: So if that potentially helps.\nICANN - MTS - A/V: I guess I'm going to be mean to you, hope you don't mind. What is in here that would not make its way into a contractual\nICANN - MTS - A/V: compliance, you know, guideline, because you're gonna… at the end of implementation.\nICANN - MTS - A/V: there'll be… Some documents that go to registrars to explain what the new obligations are.\nICANN - MTS - A/V: Is there something about the initial definition that would\nICANN - MTS - A/V: Tie your hands in that, or…\nICANN - MTS - A/V: I mean, is this the only place this can be, is what I'm asking, or could it be downstream someplace else?\nICANN - MTS - A/V: I mean, potentially, we are really just commenting on the recommendation.\nICANN - MTS - A/V: So, obviously, in implementation, when it comes to discussing how to turn this into consensus policy, it helps to be as precise as possible, because often these arguments become, you know, they're revived, and people start, people in the IRT representative start to say no, but when we meant, what we meant by this was.\nICANN - MTS - A/V: Okay, so… Our understanding was that this is what the working group.\nICANN - MTS - A/V: tended by this definition. So, where possible.\nICANN - MTS - A/V: We were asking if this is what the working group intended, maybe it's best Just to state it clearly.\nICANN - MTS - A/V: So, it involves, potentially revisiting this and implementation.\nICANN - MTS - A/V: However, it is a refinement change. It's really just to improve the clarification. We're not, suggesting, like, a change of approach.\nICANN - MTS - A/V: somewhere.\nICANN - MTS - A/V: All right, thank you. Chris?\nICANN - MTS - A/V: Thank you, Paul. And thanks, Peter, for clarifying it.\nICANN - MTS - A/V: I originally put my hand up to ask what was the justification for the wording.\nICANN - MTS - A/V: Having listened to you.\nICANN - MTS - A/V: I suppose my comment would be that I'm not sure that it is just a clarification.\nICANN - MTS - A/V: What… the sentence that's been… or the words that have been removed say, information ordinarily accessible to the registrar through its contractual obligations.\nICANN - MTS - A/V: What you've said is information the registrar is required to collect or maintain, so you have removed the ordinarily accessible.\nICANN - MTS - A/V: And it's entirely possible it could be information that the registrar was contractually obliged to collect 6 years ago.\nICANN - MTS - A/V: Which is no longer ordinarily accessible.\nICANN - MTS - A/V: So I do think it makes a change.\nICANN - MTS - A/V: By removing the reference to ordinarily accessible.\nICANN - MTS - A/V: Do you think that…\nICANN - MTS - A/V: Was ordinarily accessible a problem for you? Is that why you asked for the change?\nICANN - MTS - A/V: Thank you.\nICANN - MTS - A/V: I think we were just, I think…\nICANN - MTS - A/V: When we were looking at this, we were trying to unpack exactly what was meant.\nICANN - MTS - A/V: So.\nICANN - MTS - A/V: For us, the original information ordinarily accessible.\nICANN - MTS - A/V: through its contractual obligations, it wasn't quite clear what that meant. It obviously could vary technical systems and boost reports. So, we were trying just to make, you know, based on our understanding of what the working group intended, obviously.\nICANN - MTS - A/V: What you're saying is this is not what you intended. Take that on board.\nICANN - MTS - A/V: We just wanted, maybe just… Just to be quite clear, you know, we think this is what you mean.\nICANN - MTS - A/V: So, I take your point if this is… if you think this language is not representative.\nICANN - MTS - A/V: Thank you. Okay, we have Mark.\nICANN - MTS - A/V: Mark Trachtenberg of the IPC.\nICANN - MTS - A/V: We did discuss this a lot, and there was some significant disagreement, and there was some compromise here.\nICANN - MTS - A/V: Right, so…\nICANN - MTS - A/V: But even though the window's compromised, I think people have the ability to still make public comments to put their views on the record of what they think it should be, and…\nICANN - MTS - A/V: I think on this one, part of what we discussed is, well, why do we have to be so precise here? I can't compliance, we'll figure it out, and they'll tell us in an advisory.\nICANN - MTS - A/V: Well, now we don't have to wait. Now they're telling us how they view it. They're telling us what they view, and so they're telling us already, why put it in an advisory? Why not just be clear and put it in a policy? And again, I think we should be as clear as possible in this policy when available, and so ICANN is now telling us their view. Let's just bake it into this and be done.\nICANN - MTS - A/V: Thank you, Mark Volker.\nICANN - MTS - A/V: Yes, I think,\nICANN - MTS - A/V: we have been over this numerous times, and we had… I mean, this was one of the longer discussions that we had during the working group, and I think Reg is right when she puts in the chat that the working group intended what the working group proposed, and that was the… that was the intent, that was the language that we ultimately agreed on, and I think… I find it kind of…\nICANN - MTS - A/V: Sad is the right word, it isn't the right word, but, curious that ICANN, who was in the room and who was asked to contribute and weigh in on the suggestions that we made during the time that we discussed them.\nICANN - MTS - A/V: chose to wait with their feedback until now. I think that feedback would have been valuable and interesting at the time that we discussed it, and it could have been maybe even influenced the decision of the working group, but it was missing. Why did ICANN not make these comments?\nICANN - MTS - A/V: And voice these concerns, or bring forth these issues.\nICANN - MTS - A/V: At the time that we asked them to contribute them.\nICANN - MTS - A/V: I think… That, to me, is sad and a break in the process that could have been avoided.\nICANN - MTS - A/V: Thanks, Volker. I do want to say, however, that\nICANN - MTS - A/V: that ICANN Org is also a member of the multi-stakeholder community, right? And under…\nICANN - MTS - A/V: And under that theory, we could dismiss any public comment by anybody that had a representative around the table.\nICANN - MTS - A/V: Right? So we don't… I don't think we want to do that, but I… but I will acknowledge your frustration. How's that? I can do that.\nICANN - MTS - A/V: Reg, go ahead.\nReg Levy – Tucows: Thanks, and… As has been said, this… the verbiage was…\nReg Levy – Tucows: The result of a lot of backing and forcing.\nReg Levy – Tucows: And… It feels very much like that has been tossed out the window.\nReg Levy – Tucows: Information ordinarily accessible.\nReg Levy – Tucows: Was put first, very specifically because…\nReg Levy – Tucows: There is information that we are required to have that is not easily accessible.\nReg Levy – Tucows: And so, although we have that under our contractual obligations, and when ICANN asks us for it, we can pull that data, that's very different\nReg Levy – Tucows: From a, hopefully, reasonably quick and easy look at our files to say, okay, is there anything here that we can compare to something else that we have?\nReg Levy – Tucows: And… For example, I'm gonna say the entire who is history of a domain.\nReg Levy – Tucows: That may not be ordinarily accessible, and so I'm not going to compare all of the information that it used to have.\nReg Levy – Tucows: I will compare what is currently available.\nReg Levy – Tucows: And…\nReg Levy – Tucows: Maybe that's… maybe that's an extreme lack, and we definitely want to make sure that a domain that transferred in that is very old, that we're still looking at every single piece of everything, but… but the point of putting information ordinarily accessible\nReg Levy – Tucows: First was saying that that's the important piece.\nReg Levy – Tucows: That we have systems.\nReg Levy – Tucows: that allow us to access certain pieces of data, and that's what we're going to use, and that may differ based on what the registrar is. And as Volker said in the chat, this has been gotten over and over and over again.\nReg Levy – Tucows: And so it is a little bit frustrating to do it again. I'm happy to continue to fight this, but again, I thought we had gotten to a place where everybody was a little bit unhappy.\nReg Levy – Tucows: Which is the point of a true compromise.\nICANN - MTS - A/V: Thank you, Reg.\nICANN - MTS - A/V: Yeah, we did discuss it, for sure. Things are not thrown out the window. This is straw people text. We're… nobody is obligated\nICANN - MTS - A/V: to accept what Nick and I did to try to bring the…\nICANN - MTS - A/V: public comments in, so nothing's out the window. We're just… we're…\nICANN - MTS - A/V: taking comments on the text and the temperature of the room about whether or not we want to adopt it, right? That's all.\nICANN - MTS - A/V: Chris, go ahead.\nICANN - MTS - A/V: Thank you, Paul.\nICANN - MTS - A/V: I don't… I don't think it's particular… I understand the frustration, but I don't think it's particularly relevant to this discussion whether or not it should have been said in the room weeks ago.\nICANN - MTS - A/V: But equally, I don't think that putting up the text without some clear explanation as to what's wrong with the existing text is actually a fair way of dealing with it. So if ICANN Org believes that the text that was originally there is unclear.\nICANN - MTS - A/V: I would like an explanation of what it is that is unclear about it and why it is that their suggested text is better.\nICANN - MTS - A/V: Given that they are being… given that…\nICANN - MTS - A/V: Faced with a number of people in this room saying, It doesn't… it does… it…\nICANN - MTS - A/V: It changes the import of the sentence. You're going to need to explain what the problem was with the wording you had and why you think your wording is better. I don't think it's enough to simply say this is what we think is better. You need to say why.\nICANN - MTS - A/V: Thanks, Chris. So yeah, this is…\nICANN - MTS - A/V: An attempt to respond to the public comment, if there is a champion.\nICANN - MTS - A/V: For our straw person, happy to…\nICANN - MTS - A/V: Hear from them. We've heard from people who,\nICANN - MTS - A/V: Pointing back to how many times we've talked about this, and the fact that it was a subject of compromise.\nICANN - MTS - A/V: So if we are going to change this, even though Nick and I proposed it, and you know, because we're trying to bring in the public's comment, right? This isn't just about what we've all said around the table.\nICANN - MTS - A/V: I'm not married to this.\nICANN - MTS - A/V: Right? But if somebody thinks this is better, or if they think if there's something even different than this that's better, great, let's hear. But Chris, I think that your request that somebody… that anybody that wants to make a change should be able to defend it, I think that's fair. We're gonna hear from Ching.\nICANN - MTS - A/V: Thank you, Paul. Ching from the BC. So, I'd like to make a short point on\nICANN - MTS - A/V: the information, right? So, I think… I'm just guessing that ICANN wants more information.\nICANN - MTS - A/V: But at this particular case, more information is not necessarily useful. The right information is more useful, so I would rather, or the BC would probably rather to spend time on getting the right information instead of just more information.\nICANN - MTS - A/V: This is what I'm trying to get at. Thank you.\nICANN - MTS - A/V: Thanks, Ching. So, help me understand, is that support going back to the old, or…\nICANN - MTS - A/V: What are you advocating for? At this point, I would rather to stick with the old one, so we don't go there. But if we're going to, for example, if the IRT want to talk about what information means, I'll be happy to.\nICANN - MTS - A/V: Do it in terms of setting what's right for, you know, the information that we'd like to collect.\nICANN - MTS - A/V: Thank you, Ching.\nICANN - MTS - A/V: Back to you, Mark.\nICANN - MTS - A/V: Mark Trachtenberg, the IPC.\nICANN - MTS - A/V: If this is ICANN's view, Right?\nICANN - MTS - A/V: why put it in an advisory and just not put it into the policy? Because ultimately.\nICANN - MTS - A/V: If they put it into an advisory.\nICANN - MTS - A/V: That's what's required anyway, but now you're just adding another level of another place that people have to look instead of just baking it into the policy itself.\nICANN - MTS - A/V: So it just seems way more efficient if that's what they want.\nICANN - MTS - A/V: Like, whether people agree with it or not.\nICANN - MTS - A/V: you know.\nICANN - MTS - A/V: Parties acknowledge that we have to go with what compliance says. We've said it a million times, what would align compliance? Well, now compliance and ICANN is telling you this is what we need, this is how we view it.\nICANN - MTS - A/V: Why make people go to a different document, a different advisory, when it could just be in the policy itself? That seems inefficient to me.\nICANN - MTS - A/V: And I think this language is fine.\nICANN - MTS - A/V: Martina.\nICANN - MTS - A/V: Thank you very much, Paul, and I hear all sides around this table, I understand the frustration, but again, from a policy perspective, government perspective.\nICANN - MTS - A/V: We can be a bit concerned if ICANN Org does not feel like the text is adequate, but maybe I think ICANN Org initial interpretation of what we meant.\nICANN - MTS - A/V: It's not what we meant, so now they… we have repeated what we meant, what we mean, so maybe there's a better phrasing that can be put on the table that\nICANN - MTS - A/V: respects the compromise, the spirits of the compromise that we've reached without reopening the entire discussion, but it's not exactly the text that is here, so maybe I would put that in the hands of ICANNOR to\nICANN - MTS - A/V: Briefly, you know, think about that. I think there would be something else textually could be.\nICANN - MTS - A/V: played with to ensure that they're fine enough for implementing the policy, but as I said, we would like ICANN to tell us that it is fine.\nICANN - MTS - A/V: Thanks, Martina. Reg.\nReg Levy – Tucows: Thank you.\nReg Levy – Tucows: Since this is something that had been discussed so often, and to Tomas's, point in the chat, that should be taken into account with public comments.\nReg Levy – Tucows: The only way that I could live with this would be if it said, may include, but is not limited to.\nICANN - MTS - A/V: So it would read, \"Reasonably accessible to the registrar may include.\" But it's not limited to.\nICANN - MTS - A/V: And then the rest of it stays.\nICANN - MTS - A/V: The way it's written now?\nReg Levy – Tucows: Don't love it, but I could live with it.\nReg Levy – Tucows: I think, honestly, since we've done this so many times, that what we had before is preferable, but that seems to not be a popular position.\nICANN - MTS - A/V: Thanks Reg.\nICANN - MTS - A/V: Brian.\nICANN - MTS - A/V: Thanks, Paul. Just to note, I think that what Reg proposed sounds reasonable. But I think it might be helpful, too, to understand the change that, you know, because I understand that this came from a comment maybe from ICANN Org, but there's obviously various parts of ICANN Org. And so, is this something that actually came from compliance\nICANN - MTS - A/V: As far as a, they need this in order to\nICANN - MTS - A/V: From an enforceability perspective, or is this…\nICANN - MTS - A/V: somewhere else within ICANN organization as a preference, because those are two different\nICANN - MTS - A/V: scenarios, one of which really gets to, if ICANN compliance believes it can't enforce the policy unless it has X, Y, and Z, that's a very different, different position than a preference from elsewhere in ICANN Org.\nICANN - MTS - A/V: Thank you, Brian. We're gonna go to Jeff and ask that question, where to give us the history lesson of where the language came from. Was it compliance or someplace else? In the meantime, while you listen to him, I'd like for you to multitask and consider the Reg variant of May.\nICANN - MTS - A/V: I'm so sorry, Peter. Sorry. Sorry, Jeff. Peter.\nICANN - MTS - A/V: That's alright, I can live with Jeff. Peter Eakin from ICANN Org. Just to clarify, ICANN Org\nICANN - MTS - A/V: Regularly, indeed, it's standard that we submit public, comments on PDPs.\nICANN - MTS - A/V: And, this is the result of a cross-functional analysis that we undertake on the preliminary recommendations.\nICANN - MTS - A/V: And that is a group that comprises representation from\nICANN - MTS - A/V: lots of parts of ICANN Org, including compliance.\nICANN - MTS - A/V: So, compliance were involved in this language.\nICANN - MTS - A/V: For us, we… It is… we proposed this as a refinement suggestion.\nICANN - MTS - A/V: Simply because we believe that the language as written\nICANN - MTS - A/V: is potentially unclear as to exactly what, is intended.\nICANN - MTS - A/V: So we really just posed this to the group.\nICANN - MTS - A/V: To see, you know.\nICANN - MTS - A/V: if there was a way of potentially unpacking it a little bit, as I saw in one of the Zoom calls.\nICANN - MTS - A/V: comments that it was just much clearer of the intent. This is also with the.\nICANN - MTS - A/V: With really just thinking ahead to implementation.\nICANN - MTS - A/V: To sort of forestall, as someone says, a conversation that could happen in the IRT.\nICANN - MTS - A/V: potentially…\nICANN - MTS - A/V: It's better, we think, to, where possible, address these sorts of, sort of, ambiguities now, if possible, and if the working group agree.\nICANN - MTS - A/V: Thank you, Peter.\nICANN - MTS - A/V: Okay.\nICANN - MTS - A/V: That's all the hands.\nICANN - MTS - A/V: Let's open a queue on the Reg variant. Who could… who has a problem with the Reg variant? Who could live with it?\nICANN - MTS - A/V: It would be… we would switch out the…\nICANN - MTS - A/V: You would say, may include, but is not limited to.\nICANN - MTS - A/V: And then we keep the rest of the straw person language.\nICANN - MTS - A/V: Mark.\nICANN - MTS - A/V: kind of like Mark Trachtenberg at the IPC, what I said in the chat, we just… I don't…\nICANN - MTS - A/V: love Reddit's change, but we have to compromise here, and she's compromising by not loving the rest of the language, but being willing to live with that adjustment, so I… in the spirit of that.\nICANN - MTS - A/V: you know, I think I could…\nICANN - MTS - A/V: Or the IPC could maybe do the same, and, you know, if she's willing to get on board with that, then maybe that's a way to make this happen.\nICANN - MTS - A/V: Thank you, Mark. Where everyone doesn't get exactly what they want, but we get closer to the… to what we think is best.\nICANN - MTS - A/V: Thank you, Mark.\nICANN - MTS - A/V: Any objections to the Reg variant?\nICANN - MTS - A/V: Chris.\nICANN - MTS - A/V: It's not an objection as such, it's a clarification, and I apologize profusely for having my lawyer's hat firmly screwed onto my head right now.\nICANN - MTS - A/V: But irrespective of Reg's amendment, it seems to me that\nICANN - MTS - A/V: The switch does make a difference because it says information the registrar is required to collect or maintain under its contractual obligations.\nICANN - MTS - A/V: 1.\nICANN - MTS - A/V: to information available through its technical systems and reasonably accessible. Now, what that means\nICANN - MTS - A/V: Is that the information reasonably accessible.\nICANN - MTS - A/V: if you parse it correctly, only applies to information available through its technical systems. Now, that may not matter, I'm not a registrar.\nICANN - MTS - A/V: But it seems to me that having the information or where you say reasonably ordinarily at the beginning means it applies to everything. And as it's currently written, it only applies to information available through its technical systems. I have no idea if that makes any difference.\nICANN - MTS - A/V: But it's a point, I think, it is a point of difference in the text that needs to be clear for people to understand. Thanks.\nICANN - MTS - A/V: Thanks, Chris.\nICANN - MTS - A/V: The way I was reading it is that the first reasonably accessible in the black font.\nICANN - MTS - A/V: sort of takes care of that. We just use reasonably accessible again, which is\nICANN - MTS - A/V: common in ICANN definitions, they tend to be a little bit circular.\nICANN - MTS - A/V: I don't think because we use it later… That may be true. …that thing becomes unreasonably accessible, yeah.\nICANN - MTS - A/V: So I think we're okay. I don't like it.\nICANN - MTS - A/V: But… Ching.\nICANN - MTS - A/V: Thank you, Paul. Ching from the BC. We have a short discussion, so the BC feels that the original test and the new text, pretty much, as Chris pointed out, is pretty much the same, except the reseller part, which, if…\nICANN - MTS - A/V: If the group says, you know, the new text is better, we will actually support the new text.\nICANN - MTS - A/V: Thanks.\nICANN - MTS - A/V: ABC supports the Reg variant. Reg, do you support the Reg variant?\nReg Levy – Tucows: I…\nReg Levy – Tucows: I'm trying to make changes on the fly, and what I would really like to do is be able to type something into this so that I can read it, and… and that's not really possible right now.\nReg Levy – Tucows: Again, my preferred is what we had agreed to before, because every single piece that is in the new proposed definition from ICANN is something that we considered and did not agree to. So…\nReg Levy – Tucows: I'm trying to figure out how to make it be something close to what it was.\nReg Levy – Tucows: And the maybe, but is not limited to, As… As Chris noted.\nReg Levy – Tucows: There is a presumption in this definition as it stands that information that is reasonably accessible is not included in\nReg Levy – Tucows: information that we're required to collect or maintain, like, that those are two different sets, and I agree with that. So as long as we say it's one or the other, great. Because it should not be both. If something is not reasonably accessible, even the… wow, I almost said a vault, but…\nReg Levy – Tucows: Even though it exists, if it's not reasonably accessible, it ought not be reasonable for us to look at it, or to use it when we're considering our ADC. And again, that is what we got to at the end.\nReg Levy – Tucows: And while it is interesting to note that ICANN staff thinks that all information that we are required to collect is necessarily reasonable, the way that it was written specifically said that the WG\nReg Levy – Tucows: took that into consideration, and said that that wasn't true. And that gave us the opportunity to argue to ICANN compliance that something that we do have is not reasonably accessible.\nReg Levy – Tucows: And that we would argue with ICANN compliance about the reasonability of that specific piece of information, and it didn't have to go through\nReg Levy – Tucows: This whole process.\nReg Levy – Tucows: And I'm trying to get us back to something close to that.\nReg Levy – Tucows: So I don't know, I guess, is the answer to whether or not I still agree with my proposal.\nICANN - MTS - A/V: Thank you, Reg. Okay, I'm asking for anybody else that wants to say something about this to get in behind Tomas.\nICANN - MTS - A/V: Because I'm going to draw a line under it there. Martina, go ahead.\nICANN - MTS - A/V: Thank you very much, Paul. I'm sorry to be the one more negative on Reg's proposal, but I we're not super super comfortable with May here.\nICANN - MTS - A/V: We would prefer the ease. And I will reiterate that I think for us it's important that both registrars and ICANN are comfortable with what does this mean?\nICANN - MTS - A/V: But maybe there's some drafting that they can do together that respects the spirits of the original sentence, and we keep the ease?\nICANN - MTS - A/V: Because I think the May would open a bit of a Pandora box on our side.\nICANN - MTS - A/V: Tomas.\nThomas Rickert: Thanks so much. Hi, everybody.\nThomas Rickert: I have a question. The way I read the original language… with, ordinarily.\nThomas Rickert: Would not require a contracted party to pull data from systems that might not be part of the production system.\nThomas Rickert: What do I mean by that?\nThomas Rickert: I'm looking at this from a legal perspective, being a lawyer.\nThomas Rickert: But you know that let's say there are invoices that you need to keep for 10 years.\nThomas Rickert: But, the folks operating the abuse desk\nThomas Rickert: may be blocked from access to that system, right? Because they don't need to see that data anymore, past a certain duration. So, what is the view of the…\nThomas Rickert: Folks that, Better English speakers than me.\nThomas Rickert: I think the… The proposed language would require\nThomas Rickert: A contracted party to pull whatever data they have, even from systems that they may not\nThomas Rickert: Have access to, you know, like, the bookkeeping requirements.\nThomas Rickert: And if that were the case, then the question for the working group is, do we want contracted parties to\nThomas Rickert: to tweak their processes counter to what GDPR would require them to do, and make data that can't ordinarily be part of a production system back to the production system. I hope that I'm making myself… Yeah, it's pretty early, so I'm not leaning one way or the other.\nThomas Rickert: Just raising that, because I'm a little bit at loss with, Proposed new language.\nICANN - MTS - A/V: Thanks Tomas. We have Marc and then Volker. Marc.\nICANN - MTS - A/V: Marc Trachtenberg of the IPC.\nICANN - MTS - A/V: I understand the argument that Reg wants to make to compliance about the things that aren't reasonably accessible because they're in different technical systems or something else, but I think that with her change, and actually even without it.\nICANN - MTS - A/V: And going back to the language without Reg's change, as Martina says, I still think that Reg and registrars have the ability to still make that argument to compliance.\nICANN - MTS - A/V: Compliance says you're not. You're not complying. You didn't do a reasonable investigation.\nICANN - MTS - A/V: It's like, well, these are the things that we could look at, but we didn't look at these because they're not accessible for this reason. And then compliance could decide whether that's reasonable. So I think that argument is not precluded by this language.\nICANN - MTS - A/V: With or without Regis Change.\nICANN - MTS - A/V: It's still an argument that can be made to compliance.\nICANN - MTS - A/V: Which, I think the compliance… Would be… would take into account.\nICANN - MTS - A/V: They're not trying to unnecessarily punish the registrars, they're just trying to enforce the contracts.\nICANN - MTS - A/V: Thanks, Mark Volker.\nICANN - MTS - A/V: Yes, and… Parker Greiman for the record, for the RRSG.\nICANN - MTS - A/V: We have discussed it during the working groups, but I think it bears just bringing it back for people to have it on the top of their minds.\nICANN - MTS - A/V: when we deal with an abuse complaint, this is not a matter where we take an abuse complaint, then ruminate on that for a day or two, then we look at the data that we may have available in all the databases, and spend days and days on each abuse report to make sure that we find all the data that we have available to it.\nICANN - MTS - A/V: And then we decide on that. Looking at an abuse complaint has to be done… doable in 5 to 10 minutes.\nICANN - MTS - A/V: That is the time that we have available to us to, action… to review, action, and, notify.\nICANN - MTS - A/V: that sounds like a little, because it is. However, that's the reality of how these reports have to be done, because of the volumes that we're receiving. If we are expected to look at non-production databases, reach out to resellers, what they… information they may have available, because that's in there as well.\nICANN - MTS - A/V: That, for example, that we outsource to them, because they own the customer relationships.\nICANN - MTS - A/V: And do all these extra steps.\nICANN - MTS - A/V: For every abuse complaint that we receive that might warrant an ADC,\nICANN - MTS - A/V: Do you want more abuse that we take care of less abuse? Is that the goal here? If that's the goal here, is that way we… if that is where we are, then that's what you can have, but…\nICANN - MTS - A/V: I'm not sure that anyone will be satisfied with the result of that. The result should be a process that's workable, that's fast, expedient, and that produces results.\nICANN - MTS - A/V: If that's not the goal, then I'm not sure why we're here.\nICANN - MTS - A/V: Thanks, Volker. So… I said I would draw a line, after…\nICANN - MTS - A/V: I forgot who it was.\nICANN - MTS - A/V: And we've had 3 more pop up.\nICANN - MTS - A/V: So, I'm gonna get criticized for this, because everybody will say I don't draw lines when I say I'll draw lines, but okay, we're almost done with the BDP.\nICANN - MTS - A/V: So, we're gonna hear from… we're gonna hear from Mark again, then Chris again, and then Yao.\nICANN - MTS - A/V: And then that'll be it, and then we'll have to decide what to do with this one. Mark, go ahead.\nICANN - MTS - A/V: Marc Trachtenberg for the IPC.\nICANN - MTS - A/V: I think the language that Fayo put in the chat is very helpful here, because it makes it extremely clear\nICANN - MTS - A/V: that… A reasonable investigation does not require consideration of every category in every case.\nICANN - MTS - A/V: And so this language, like, creates the universe for what's available, what could be reasonable, but then it's also limited by this implementation guidance, which makes clear that the registrar does not have to consider every one of these pieces of data. So I think that is a very helpful limitation and ensures\nICANN - MTS - A/V: that Reg and, you know, Volker and anyone else who wants to make the argument that something was not reasonably accessible, and that's why they didn't look at it.\nICANN - MTS - A/V: They're able to do that.\nICANN - MTS - A/V: It's just… The language makes clear that all… the other language includes, like, what is the universe of what\nICANN - MTS - A/V: you know, What is reasonably accessible?\nICANN - MTS - A/V: But again, you don't have to look at every single thing. That's up to the discretion of the registrar.\nICANN - MTS - A/V: Thanks, Mark. Chris?\nICANN - MTS - A/V: Thank you, Paul, and I apologize for raising my hand again.\nICANN - MTS - A/V: I may be slightly confused, and if I am.\nICANN - MTS - A/V: I apologize again in advance. If I understand it correctly, the intent of this change is to clarify\nICANN - MTS - A/V: What the original wording meant. Not to change it.\nICANN - MTS - A/V: So, not to change the meaning of it. And so…\nICANN - MTS - A/V: Arguments about the substance aren't really relevant. The question is, does this language change What was said before.\nICANN - MTS - A/V: substantively, or is it merely a clarification? So, could I suggest that maybe the answer to… the way to deal with it might be to let the people who care about it think about it for a little while, consider the words properly, and maybe come… if it's at all possible, maybe come back to it?\nICANN - MTS - A/V: Perhaps at the next session briefly to see whether or not they believe the wording means the same. 'Cause to ask, it's legal wording.\nICANN - MTS - A/V: as it's currently written. I suspect it may well have been written by a lawyer, I could be wrong.\nICANN - MTS - A/V: And therefore it may be helpful to let Volker and Reg and registrars look at it and see if, in fact.\nICANN - MTS - A/V: They think it makes… it is simply a clarification, or it does make a… it makes a substantive difference. Thanks.\nICANN - MTS - A/V: Thanks, Chris. The problem with kicking the can into the next session is we're not going to get done.\nICANN - MTS - A/V: Right? And so, I hate to be that guy, but everybody had this for several days, and if we…\nICANN - MTS - A/V: start kicking the hard stuff into the next session. We're going to end up kicking half the issues out on Thursday.\nICANN - MTS - A/V: So, yeah.\nICANN - MTS - A/V: Yeah, thank you. This is Yao for NPOC. Yeah, I agree with you, we need to make a decision today about this.\nICANN - MTS - A/V: My concern is… Really, to…\nICANN - MTS - A/V: try to understand why this, the agreed recommendation we already have for this addition is not.\nICANN - MTS - A/V: supportive of the compliant task that ICANN or ICANN compliant will do if we maintain the recommendation as it is initial without any addition.\nICANN - MTS - A/V: And even though with the… with the suggestion Reg made, which I'm not totally against, but I also think with the addition of wording, like resellers and other things, my…\nICANN - MTS - A/V: We need to reconsider a role like, see what Other implication, this…\nICANN - MTS - A/V: will imply, if we keep it like that. So, suggestion line here would be, why not keeping what we agreed on so far, and then the addition of the… for me, it's like a clarification.\nICANN - MTS - A/V: Then we put it into into the implementation guideline.\nICANN - MTS - A/V: So then we have a grinder. Okay.\nICANN - MTS - A/V: Thanks, y'all.\nICANN - MTS - A/V: Alright, so… That's a good… that's a good idea.\nICANN - MTS - A/V: They're, they're… you know, if we're going to change something that was a subject of significant compromise, and history will record that this was\nICANN - MTS - A/V: a significant disagreement between the IPC and the registrars, and it was resolved through the compromise language that appears in black font.\nICANN - MTS - A/V: Folks, we need for that to be by wild acclaim, everybody claps and says we did a great job, right? So…\nICANN - MTS - A/V: This will remain as it was. And we were gonna, you know, we have some implementation guidance to look at.\nICANN - MTS - A/V: There's an IRT ahead.\nICANN - MTS - A/V: There are advisories by compliance.\nICANN - MTS - A/V: So we're gonna have to just trust the universe to unfold.\nICANN - MTS - A/V: And we're moving on.\nICANN - MTS - A/V: All right?\nICANN - MTS - A/V: And I know that I probably made some people unhappy, but… Okay.\nICANN - MTS - A/V: Let's go to the next item.\nICANN - MTS - A/V: Record comment 4?\nICANN - MTS - A/V: Okay.\nICANN - MTS - A/V: Hi, everyone. So now we are seeing here, the main common clusters for Recommendation 4 and Implementation Guidance 4.1. There was one fairly editorial change that caused some confusion, the AND, OR, when we listed the non-exhaustive list.\nICANN - MTS - A/V: Furthermore, many commenters suggested… suggested, sorry, to expand the list of indicators.\nICANN - MTS - A/V: However, the working group noted that this is just a non-exhaustive list to take into consideration for various reasons, so we can provide some rationale or a clarification what the intent of this list is.\nICANN - MTS - A/V: is Furthermore, there were some comments on, why this seems too flexible, why is not one\nICANN - MTS - A/V: category mandatory. Also, we note that the working group discussed this before, and there were very clear reasons why the working group wanted to keep the list as is, because not all indicators result in the same.\nICANN - MTS - A/V: or are connected to the same, so I think that is what the next two slides would want to clarify and just strengthen the working group rationale and intent with recommendation 4.\nICANN - MTS - A/V: So I hand over to Paul to introduce those.\nICANN - MTS - A/V: Thank you. There was a question in the chat, which I've just responded to from Jothan. That is correct. We are not adopting the red text, we are moving back to the black font text.\nICANN - MTS - A/V: Okay, I need the next slide. Here we go.\nICANN - MTS - A/V: So, here's the proposed update. Again, a straw person. This is just what leadership tried to do to incorporate public comment. It is not binding, and as we saw from the last\nICANN - MTS - A/V: Rec. It is completely pushed back uponable. Is that a word pushed back uponable?\nICANN - MTS - A/V: I just created a new phrase. Okay? So the proposed new language to determine whether association exists. A registrar must take into consideration reasonably accessible indicators.\nICANN - MTS - A/V: That are relevant under the circumstances, and likely to yield useful information.\nICANN - MTS - A/V: Such indicators may include, as applicable.\nICANN - MTS - A/V: Registered name holder or account-related information.\nICANN - MTS - A/V: technical indicators and indicators of coordinated activity or registration patterns.\nICANN - MTS - A/V: When determining association, the specific elements considered in any given ADC, even within a single registrar, may vary depending upon the particular circumstances.\nICANN - MTS - A/V: So, let us… I'm sorry. Oh, there's another slide. Okay, sorry. All that's Get to that.\nICANN - MTS - A/V: And then the idea is to add to the implementation guidance.\nICANN - MTS - A/V: After the current non-exhaustive list.\nICANN - MTS - A/V: These indicators are illustrative and non-exhaustive, and their evidentiary weight may vary depending on the circumstances.\nICANN - MTS - A/V: No single week or commonly shared infrastructure indicator necessarily establishes association or common control. In such… in such…\nICANN - MTS - A/V: Apologies. In some circumstances.\nICANN - MTS - A/V: One sufficiently specific indicator may support a reasonable determination of association. In other circumstances, multiple indicators may need to be considered together, okay?\nICANN - MTS - A/V: All right, let's, open… Q on this, can I hear from Reg?\nReg Levy – Tucows: Reg Levy from the Registrar Stakeholder Group. Strong support! I love it! Can we go back to the other slide? I have a slight quibble. Grammatically, there should not be a comma before the second AND. It should either be a colon and no AND, or simply no comma. Otherwise, love it! It's great!\nICANN - MTS - A/V: Death to the comma.\nICANN - MTS - A/V: All right.\nICANN - MTS - A/V: Anyone else have anything to say about this one?\nICANN - MTS - A/V: Jothan.\nICANN - MTS - A/V: I… and… I'm, Jothan Frakes for the record, I'm here with my SAC hat on.\nICANN - MTS - A/V: Really principally, it might be the case that, there may be signals that are… A.\nICANN - MTS - A/V: Not relevant, as well. That could be, that may not be actually indicators that might, under other circumstances, show\nICANN - MTS - A/V: association in other circumstances. So there's a… there's a larger fact pattern to look at on these.\nICANN - MTS - A/V: Thank you.\nICANN - MTS - A/V: Thanks, Jothan. Does that…\nICANN - MTS - A/V: Do we need to consider a textual change for that, or is that a general comment?\nICANN - MTS - A/V: I just take it as a general comment. I don't think that's additive. Thank you.\nICANN - MTS - A/V: Thank you.\nICANN - MTS - A/V: Any other hands? Anybody want to…\nICANN - MTS - A/V: Anybody? Oh, Michaela, thank you.\nICANN - MTS - A/V: Hi, Michaela, for the record. I'm… maybe this is just my brain, but I'm having a little trouble with the sufficiently specific indicator.\nICANN - MTS - A/V: Like, that's not a criterion I recall us discussing, and that seems like that brings in significantly new language to consider, as an… I think that's just language I'm a little confused on. I don't know if we could provide some more clarity on that.\nICANN - MTS - A/V: similarly, again, might just be a little jet-lagged, but I'm a little confused as to how… okay, so no singular… no single week or commonly shared indicator, la la la. But then, in some cases, one is sufficiently specific. It just seems, like, slightly logically confusing, but…\nICANN - MTS - A/V: again, if others… if it makes sense to others, that I'll defer to the group consensus, but I think I'm a little confused about the logic of\nICANN - MTS - A/V: No singular one, but then sometimes one singular is enough.\nICANN - MTS - A/V: But maybe that's just the phrasing there.\nICANN - MTS - A/V: Thanks, Michaela. I'll try to explain what we try to do with this. And I actually think the problem is that we…\nICANN - MTS - A/V: We put sufficiently, right? That word is sort of redundant with the other thing, because if it does support a reasonable determination of association, it was therefore sufficient, right?\nICANN - MTS - A/V: And so the idea behind no single weak or commonly shared infrastructure indicator necessarily establishes association or common control. Think about that in terms of, like.\nICANN - MTS - A/V: DNS records, right? That, you know, if you… when you register your domain name, you sign up for your registrar's DNS, right? Well, my domain name for my law firm probably shares DNS records with, you know, a million other websites.\nICANN - MTS - A/V: And so it wouldn't…\nICANN - MTS - A/V: follow that, you know, that would be an indication that I'm associated with those domain names, right? So, that's an example of a weak infrastructure. association. But in some circumstances, one… and I scratched sufficient… I don't… sufficiently, I don't like it.\nICANN - MTS - A/V: One… even though I… even though it's there. Okay, one specific indicator may support a reasonable determination of association. So, for example, if\nICANN - MTS - A/V: There was a maliciously registered domain name.\nICANN - MTS - A/V: by Fred Flintstone, who actually, I think I had a UDRP against at one point in my career.\nICANN - MTS - A/V: And in that account is another maliciously registered domain name, also by Fred Flintstone. That would be an indication.\nICANN - MTS - A/V: That's… that, to me, would be sufficient, right? And it's only one\nICANN - MTS - A/V: one thing. So what we were trying to do with capturing this language is to explain how the sliding scale works, right?\nICANN - MTS - A/V: And this is, this is something that, you know, Nick and I are both lawyers, so we're comfortable with because we're used to it, and especially in trademark law, we're extra used to this, right? Because no one indicator of the nine factors controls, you know, it's, you know.\nICANN - MTS - A/V: Some can be weak, some can be strong. So that was the idea behind it, and it was actually meant to protect\nICANN - MTS - A/V: Does that make sense? Instead of saying, oh, one info… oh, you have the same DNS because you're all reg… you're… you're all registered through Namecheap, well, then you're all guilty, right? We're trying to keep that from happening.\nICANN - MTS - A/V: Okay? Yeah, Michaela, sorry, go ahead. Yeah, Michaela, just responding to that, so maybe this is more grammatical than anything, because it sounds like, okay, so no singular a lot, unless in some circumstances there is… like, sometimes there are cases where it's sufficient, where it's one indicator, if I understood correctly, and I think the way it's…\nICANN - MTS - A/V: phrase now. Again, I'm not a lawyer, I'm not… specifically not a trademark lawyer, so maybe this is just language I'm not following, but I do want to make sure that it is comprehensible, because right now it just, again, seems logically confusing.\nICANN - MTS - A/V: In some, it is sufficient, some… but not sometimes.\nICANN - MTS - A/V: So I think if we could maybe try to play around with that language, just to make it a bit clearer, that would be appreciated. But again, if others… if it is understandable to others.\nICANN - MTS - A/V: I'll defer my point, but I'm a bit confused still. Thanks. But I get the spirit of what you're trying to convey, just not the way it's framed now.\nICANN - MTS - A/V: Thanks, Michaela. I guess what I'm going to do is to hit that pickleball back into your court and say, come up with the language that will make you comfortable.\nICANN - MTS - A/V: And you can work on that while we talk to Reg Reg, go ahead.\nReg Levy – Tucows: Don't change it. Reg Levy from the… from Tucows and the Registrar Stakeholder Group. Michaela, I do understand where you're coming from, but this makes total sense to me. And in our registrar back channel, many others.\nReg Levy – Tucows: It's not just a single indicator.\nReg Levy – Tucows: It's a single week indicator.\nReg Levy – Tucows: Or it is a single, commonly shared infrastructure indicator.\nReg Levy – Tucows: Versus…\nReg Levy – Tucows: a sufficiently specific indicator. So, Volker put some stuff in the chat, but again, this makes total sense to me, and I'm absolutely on board with it. I can't just say.\nReg Levy – Tucows: Well, it's using Cloudflare, so here's a million other domains with Cloudflare infrastructure, therefore there's no associated domains.\nReg Levy – Tucows: That doesn't constitute a sufficient review because it's a weak indicator.\nReg Levy – Tucows: What I have to do is look and see, oh, this is registered by Fred Flintstone. I've got 4 other remains registered by Fred Flintstone's.\nReg Levy – Tucows: For some reason, that's a tongue twister for me.\nReg Levy – Tucows: I've got 4 other domains registered by this person.\nReg Levy – Tucows: So that is a sufficiently specific indicator. And… and it's going to be up to me to justify to ICANN which ones I used, and which… and whether or not they are considered weak or sufficiently specific. So I do understand where you're coming from, but I strongly…\nReg Levy – Tucows: Hope that I've explained it well so that there are not changes.\nICANN - MTS - A/V: Thanks Reg.\nICANN - MTS - A/V: Mark?\nICANN - MTS - A/V: or Trachtenberg for the IPC.\nICANN - MTS - A/V: I'm generally… I think we're generally okay with all this language. I understand all the points raised, I agree with\nICANN - MTS - A/V: Michaela's point about sufficiently specific.\nICANN - MTS - A/V: I also understand and agree with what Reg is saying. I think maybe the solution to make it logically consistent is to replace sufficiently specific with strong.\nICANN - MTS - A/V: Right, because you say, no single weak or commonly shared infrastructure indicator necessarily establishes association or common control, but in some circumstances, one strong, which is the opposite of the weak.\nICANN - MTS - A/V: makes it logically consistent, and I think accomplishes the concerns that were raised by Reg and Michaela, and I think gets us to where we need to be, hopefully, if people are okay with that.\nICANN - MTS - A/V: Maybe Reg could respond?\nICANN - MTS - A/V: Thanks, Mark. Well, Michaela was next, but hopefully Reg can respond. Michaela?\nICANN - MTS - A/V: I mean, I think from my side, I would have to triple check with the NCSG, but I think, to me, that sounds fine. I think that was the… I was confused about the comparison, single week versus sufficiently specific. So, to me, Mark, that's a great solution from my view, but I'll just triple check quickly and come back in the chat on that. Thanks.\nICANN - MTS - A/V: Thank you, Michaela, and remember, Nick and I are not married to this text, we were just trying, so no one's hurting our feelings by changing\nICANN - MTS - A/V: All right. Volker.\nICANN - MTS - A/V: Thank you, Volker Greimann for the RRSG. I think this is necessary because it also matches our realities in how we deal with these things.\nICANN - MTS - A/V: If…\nICANN - MTS - A/V: We were nailed down to, always using the same indicators the same way, then we might be forced to,\nICANN - MTS - A/V: have bad decision making in the process.\nICANN - MTS - A/V: As an example, if we find certainly sequentially generated domains associated with a certain type of abuse, and can reasonably determine that they're all linked because of their naming conventions.\nICANN - MTS - A/V: That doesn't mean that we have to treat all sequentially named domains that have been generated in the same manner by an algorithm, for example, the same way, because if we cannot link all of them to that kind of abuse, or they're used differently, then that might not be an indicator of abuse.\nICANN - MTS - A/V: We must be able to treat similar.\nICANN - MTS - A/V: topics differently, depending on the circumstances, and therefore certain circumstances that make us do something may not make us do something. In another case.\nICANN - MTS - A/V: Thanks, Volker.\nICANN - MTS - A/V: from my point of view, correct, right? We are trying to take the non-robotic\nICANN - MTS - A/V: approach, right? We want humans looking at this and balancing factors.\nICANN - MTS - A/V: Rod?\nICANN - MTS - A/V: Yeah, Rod Rasmussen of the SSAC.\nICANN - MTS - A/V: not on the topic that we've been talking about clarifying the language here, but I want to make sure to get in, since we're talking about the implementation guidance for 4.\nICANN - MTS - A/V: I wanted to point out that the SSAC has published SSAC 1, or SAC 135.\nICANN - MTS - A/V: That was… but that was noticed. It was… so we didn't have direct input on the particular language in the… in the worksheet, but we did publish 135.\nICANN - MTS - A/V: That has been noted by others as well. In that SSAC document, we have a fairly… Comprehensive…\nICANN - MTS - A/V: Analysis of different indicators, etc, that can be used, and how to combine them, etc.\nICANN - MTS - A/V: And I would also note that several of the other public comments\nICANN - MTS - A/V: got into some of these areas that I think were quite useful in many of them. Some approaches that were, unique that, were not covered by the SSAC document as well.\nICANN - MTS - A/V: I bring this up because I think that we have a list in the implementation guidance right now. I know it's non-exhaustive.\nICANN - MTS - A/V: It's also non-authoritative, and we now may have some authoritative resources we can point to, such as the SAC 135 document.\nICANN - MTS - A/V: That might be worth adding.\nICANN - MTS - A/V: A bit here to look for implementation guidance, to look towards authoritative\nICANN - MTS - A/V: work in this topic area, and SAC 135 might be one of those to add. Thanks.\nICANN - MTS - A/V: Thanks, Rod. Chris?\nICANN - MTS - A/V: Thank you, Paul. Just in an attempt to clear up the misunderstandings on the wording or maybe make it a bit clearer. Part of the issue I think is that in the second sentence you say no single weak or commonly shared infrastructure indicator. I assume that in the next sentence where it says sufficiently specific indicator that you also mean infrastructure indicator, right? So that's the same thing.\nICANN - MTS - A/V: Because you've referred to one sentence as indicator and another sentence infrastructure indicator. So I'm assuming they are intended to be the same thing. That's my… that's the first point. Second point is that in the second sentence, it doesn't actually describe the infrastructure indicator in any way, and I know that there's been use of the word strong has been… has been brought up, but it seems to me\nICANN - MTS - A/V: That if we simply said.\nICANN - MTS - A/V: In some circumstances, one sufficiently specific infrastructure indicator may support a reasonable determination of association.\nICANN - MTS - A/V: In other circumstances, For example, where the indicator is weak.\nICANN - MTS - A/V: multiple indicators may need to be considered together. In other words, string it, put it the other way around, make the clear statement about it is possible for it to be… for one indicator to be enough, but there are circumstances in which one indicator may not be enough, which includes where it's weak.\nICANN - MTS - A/V: Thanks, Chris. I think that's significantly different than what we were trying to accomplish. We were not trying to\nICANN - MTS - A/V: to limit the strong indicators to just infrastructure indicators, right? So the Fred Flintstone idea? Yeah.\nICANN - MTS - A/V: So, but Chris, go ahead. Well, no, that's fine. If I've misunderstood, then I'm happy that it's not clear because I misunderstood it.\nICANN - MTS - A/V: We're trying to call out the weakness of infrastructure indicators because they show up as a commonality.\nICANN - MTS - A/V: As opposed to a very specific, or group of specific Or strong, under the…\nICANN - MTS - A/V: Mark variant. Strong indicators, like Fred Flintstone.\nICANN - MTS - A/V: Showing up as the registrant, like, for a handful.\nICANN - MTS - A/V: Ching.\nICANN - MTS - A/V: Thank you, Paul. Ching from the BC. So, the more I read it, the term of… the term of evidentiary weight start to pop up more. So I actually put my question there, but I'd like to… just to clarify.\nICANN - MTS - A/V: So the example I'm giving now is, for example, there's five domains under one RNH, right? But only three resolved, right?\nICANN - MTS - A/V: So two is not resolved. So three sharing you know one IP right. So in this text. So we're saying if registrar A has this thing this thing happening. So registrar B has the same thing happening.\nICANN - MTS - A/V: So that means that we will be… this will be acceptable.\nICANN - MTS - A/V: for ICANN that the ADC for Registrar A, for example, the end result is 5, and the Registrar B, the same scenario, but in Registrar B, they can only do, 3, to group 3 names, in one ADC group.\nICANN - MTS - A/V: Does that mean that we are okay with this type of You know, evidentiary weight.\nICANN - MTS - A/V: Just a question, to put it out there.\nICANN - MTS - A/V: So, if I'm understanding the question, I think that answer, without the specific example, I think that answer is yes, right? Like, we want registrars thinking for themselves, right? So, because if we build out a very prescriptive policy.\nICANN - MTS - A/V: it ages out as soon as we leave the room, because the bad guys thought of something else, right? Can I… yeah. So I'd just like to make sure the group understands this, so…\nICANN - MTS - A/V: Even the scenario is the same. Once again, 5 names.\nICANN - MTS - A/V: under different, ARNETCH\nICANN - MTS - A/V: Three IP… three share one IP, the other registrar… I mean, the other RNH does the same, but the groove is fine that the end result from registrar A to registrar B could be different.\nICANN - MTS - A/V: Okay, thanks, Ching.\nICANN - MTS - A/V: Yeah, it could be.\nICANN - MTS - A/V: And the only way to change that is to have a centralized whatever, and that's not what we did here.\nICANN - MTS - A/V: For good reasons. Not the least of which is competition law.\nICANN - MTS - A/V: Okay. Any other comments on this?\nICANN - MTS - A/V: Michaela, go ahead.\nICANN - MTS - A/V: Thanks, Michaela, for the record. I… I don't want to throw a wrench into this, but I think the NCSG is still…\nICANN - MTS - A/V: confused about this language, and I promise it's not just me and my jet lag. So what we wanted to propose, perhaps to make it a bit clearer and easier, is we really like that first sentence. So these indicators are all the way to depending on the circumstances.\nICANN - MTS - A/V: And we feel like that is more than sufficient, and we also have in…\nICANN - MTS - A/V: the… in the rationale for 1 through 4, that no single data point will be determinative in all cases. So, from the NCSG's point of view.\nICANN - MTS - A/V: I think we've already covered the fact that no singular one is a sufficient indicator, and I think it's pretty clear also that given the evidentiary weight may vary, and, like, the… just that first sentence should be sufficient\nICANN - MTS - A/V: To cover everything else that's currently in red.\nICANN - MTS - A/V: That's our view, and happy to hear what others think about that proposal. So striking everything after that first sentence, but still adding that first sentence. Thanks.\nICANN - MTS - A/V: Thanks, Michaela. Martina.\nICANN - MTS - A/V: I hear Michaela and I appreciate the suggestion and of course we can consider, but I do understand from reviewing all the comments indeed that there were people a bit confused about all this.\nICANN - MTS - A/V: And I also appreciate that the Reg and Volker seem happy with this language because it does seem to reflect an operational reality, which is that if you have a very weak indicators, you need more to connect the assessment. If you have a very strong one, maybe that's sufficient.\nICANN - MTS - A/V: in terms of clarification, and especially because people have expressed this need. I'm not sure we would need to delete everything. And I I think Reg's explanation was quite clear. So I I don't know.\nICANN - MTS - A/V: how we could do to make it better, but striking it all together, I mean, we can consider, but I think there is a value in having these examples. Maybe you can take it up with the registrars and see if there is any language that would make it clear from your perspective.\nICANN - MTS - A/V: which would maintain the examples, which I think were useful for the community. But it's just a suggestion.\nICANN - MTS - A/V: Thank you, Martina.\nICANN - MTS - A/V: All right, we have Mark. Anybody that wants to speak on this should get behind Mark, and…\nICANN - MTS - A/V: Please don't jump in again and make me… you know.\nICANN - MTS - A/V: Ruth.\nICANN - MTS - A/V: make me have to, you know, extend the queue when I said I wouldn't. Otherwise, y'all are not gonna believe me. Mark, go ahead.\nICANN - MTS - A/V: Mark Trachtenberg with the IPC.\nICANN - MTS - A/V: I mean, I think I or we are okay with\nICANN - MTS - A/V: either Martina's suggestion of striking all that other language, but I also see the value of having the examples in there, which is fine, too. I just…\nICANN - MTS - A/V: Don't love specific, sufficiently specific. I think that\nICANN - MTS - A/V: It's like you could say that you know the the name servers are sufficiently specific. They are. They're specific. It's one thing, I think.\nICANN - MTS - A/V: Personally, strong seems to capture it better. I understand Reggie objects to it. I'm not really sure I understand the objection, but…\nICANN - MTS - A/V: So, I'm good with just the first sentence, or the whole sentence, but just doing something that's sufficiently specific, and if strong's not good, maybe a different word could be picked to kind of capture what I think we all… everyone seems to agree on the concept.\nICANN - MTS - A/V: Right? I don't think anyone seems to disagree, and everyone's trying to achieve the same thing. Maybe we could just…\nICANN - MTS - A/V: Find a different word, or… Make people happy that we're… Saying what we mean.\nICANN - MTS - A/V: Thank you, Mark. Okay. I don't see any other hands.\nICANN - MTS - A/V: Trying to balance what I've heard, it sounds like…\nICANN - MTS - A/V: Most of the people in the room are okay with this text, even if we don't change specific to strong.\nICANN - MTS - A/V: I do think it conveys meaning.\nICANN - MTS - A/V: And, we do have the NCSG wanting to strike the last two, but on the other hand.\nICANN - MTS - A/V: This implementation guidance is to registrars, and they're happy with it.\nICANN - MTS - A/V: And… Help that it, you know, they think it helps explain.\nICANN - MTS - A/V: So… I think, you know, we may fiddle with the text a little bit and bring it back to you guys in the next reading, but…\nICANN - MTS - A/V: I think the concepts are going to stay.\nICANN - MTS - A/V: All right.\nICANN - MTS - A/V: Let us… Is that it?\nICANN - MTS - A/V: Okay.\nICANN - MTS - A/V: All right. Is there anybody around the table or in the room that\nICANN - MTS - A/V: Believes they did not get a chance to say anything they would like to say. As before.\nICANN - MTS - A/V: This doesn't mean that you'll get your way, but if you've not had a chance to say it, let's hear it, and maybe you will get your way. Who knows?\nICANN - MTS - A/V: Anybody did not feel heard.\nICANN - MTS - A/V: Okay.\nICANN - MTS - A/V: Great. Well, once again, guys, good job. And, tomorrow's our session.\nICANN - MTS - A/V: Sunday morning at 1315.\nICANN - MTS - A/V: And in the GNSO Council Room right here.\nICANN - MTS - A/V: Everybody have a lovely time. I hope you get a few minutes to yourselves outside. It is beautiful.\nICANN - MTS - A/V: Thanks very much.\nICANN - MTS - A/V: And you can end the recording.", "scope": "whole_published_caption_track", "source_sha256": "022f3d1cec66d2a941ab2caf0e5b0049126516ed81bf258642ef9d7d08218245", "attribution": "Made by AgentCommunity // Balázs Némethi", "terminology_correction": { "accepted": [], "rejected": [ { "proposal": { "segment_id": 62, "before": "ICANNORC", "after": "ICANN Org", "evidence": [ "OFFICIAL_SESSION" ], "reason": "Corrects misspelling of organization name to canonical form." }, "reason": "Spelling edits must preserve word count; phrase rewrites are unsupported" }, { "proposal": { "segment_id": 64, "before": "Eigenorg", "after": "ICANN Org", "evidence": [ "OFFICIAL_SESSION" ], "reason": "Corrects garbled reference to ICANN Org." }, "reason": "Spelling edits must preserve word count; phrase rewrites are unsupported" }, { "proposal": { "segment_id": 193, "before": "ICANNOR", "after": "ICANN Org", "evidence": [ "OFFICIAL_SESSION" ], "reason": "Corrects truncated organization name." }, "reason": "Spelling edits must preserve word count; phrase rewrites are unsupported" } ], "response_sha256": "b9591fab60873e901c864125fa728b7d3805361e2dfeb41d41fdca793f8b2a69" } }