
47:56
Does he have the time to do this and to be involved in the ODP discussions with ICANN? I thought he left his chair position because of other commitments

59:43
Please review ICANN Expected Standards of Behavior here: https://www.icann.org/resources/pages/expected-standards-2016-06-28-en

01:19:03
6 weeks for comment period for comment period; 4 weeks to incorporate changes.That leaves 42 weeks to ready initial report. (Is that 42 meetings?) Were there 78 topics?

01:19:21
I would leave it to the WG to determine a timeline after convening

01:19:45
Is there super urgency needing the 12 month limit?

01:19:52
Kurt - Yes and no.....there is a LOT of overlap in the topics and once decisions are made, other topics will be very easy to move forward.

01:20:04
@Kurt @All, that is preferable. It will be the EPDP-IDNs and its Chair to be accountable to delivering to the committed delivery dates.

01:21:27
Also not of importance. All projects require a relief valve. Hence the PCR, Project Change Request for changes in scope or timing or resource. BUT, PCRs are a last resort option once deliverable dates are committed to.

01:21:52
Also <note>

01:22:08
Agree with Kurt, sounds like it could be confusing if the overlaps result in divergent views between groups

01:24:36
I will find that letter and post it.

01:27:08
I wouldn't say that IDNs were not a priority. Its just that there are so much complexities.

01:27:13
“The next round might be delayed for the completion of the IDN EPDP” makes no sense. Why delay the next round, which will affect <1% of IDN registrations going forward. If the Board’s concern is valid, it would make more sense to suspend all IDN second-level registrations until the IDN EPDP is completed. (And of course, this doesn’t make sense.)

01:27:28
GNSO Working Group Guidelines state 6.2 A Charter is expected to include . . . expected deliverables, key milestones, and a target timeline - all of which can, if necessary, be further refined by the WG at its onset in conjunction with the CO.

01:28:18
It is also the strong opinion of the APRALO from At-Large and the ALAC/At-Large community statements re SubPro that IDN's should be a key focus of any next round

01:28:59
See https://www.icann.org/en/system/files/correspondence/botterman-to-langdon-orr-neuman-30sep20-en.pdf

01:29:03
Page 7

01:29:05
topic 25

01:30:37
Letter F of that topic

01:31:20
@Jeff thanks for the pinpoint

01:31:54
so it will be up to the WG of IDN ePDP

01:32:18
Subject to Council approval I would assume

01:32:33
So if the group comes back and says 5 years?

01:38:19
Many thanks to the Charter Drafting Team!

01:38:52
Thank you Pam!

01:41:37
Thanks, Kurt

01:42:19
We will be sure to have a more fullsome discussion as soon as possible.

01:42:27
Nice job Dennis

01:42:33
+1

01:42:45
Thank you Kurt, Maxim

01:44:54
without inclusion of ccTLDs it will not be universal

01:47:57
@Maxim - good point. The report notes this and also points out that without many other players in the overall DNS ecosystem beyond those in ICANN, there will not be universal standards either. The report looks towards how we bring this wider ecosystem together to define such standards and processes. Its an ambitious goal, but if incident responses are not normalized throughout the broader ecosystem which includes DNS-specific players, we will continue to have silos and large inefficiencies.

01:48:19
Maxim, continuing a conversation we were having the other day, how could we do outreach with ccTLDs to align with us other than asking politely? Do we have any mechanism at all?

01:48:42
(repeated message to reach all those present)Maxim, continuing a conversation we were having the other day, how could we do outreach with ccTLDs to align with us other than asking politely? Do we have any mechanism at all?

01:49:00
@Mark , each ccTLD has own ideas

01:49:05
Exactly

01:49:18
and they will not be happy to follow

01:49:26
so no

01:49:50
The best we can hope is that a strong ICANN position would have a cascade effect

01:50:01
Point to a set of norms that are the industry standard

01:50:12
Which is why I still believe this is very worth our time

01:50:34
this seems to be quite optimistic

01:51:08
I'm pretty much a ray of light, don't you know >:)

01:51:36
A related example to the ccTLD issue is that different countries have different requirements on abuse reporting. For example, some countries require abuse reports/requests for action to be either sent directly to their national SIRT or at least be reported to them. Service providers, including registries and registrars, but also ISPs and web hosts may have to have a “ticket” from their national SIRT to take action.

01:52:54
That is an interesting point, Rod. Do we even have a master list of those contact points from the ICANN side? Or only from the M3AAWG and so forth?

01:54:19
It would be really useful for global interoperability for such processes to be standardized as much as possible, and for the correct entities to be provided the right kind of evidence for action. We outline these issues and the need for convening some sort of discussions and a potential mechanism to lead to such abuse handling standards that all can at least understand even if they have some additional or different items they may need or limitations on action imposed on them.

01:55:52
@Mark - not publicly available to my knowledge. This is one of the things we would be looking for a “common facilitator” to provide. Right now this is very siloed information, with the best resource probably being FIRST’s list of worldwide SIRTs.

01:56:16
SIRT = Security Incident Response Team :-)

01:56:31
Definitely something to look into, longer term. I am making a note of that.

01:56:41
since laws worldwide are different - there might not be a unified way at all

01:57:03
Not from the legal side, but from the procedure side they can probably be approximated

02:00:49
evidentiary standards vary per jurisdiction (in criminal laws)

02:01:34
The CPH gave us a briefing on the last call which talked about all of the work they were doing on this both within the CPH, but also within I&J

02:03:08
@Maxim - we are looking for interoperability, not necessarily the same way to do things everywhere.

02:03:13
@Maxim supposing we had a fairly strong reporting standard as a basis within ICANN, it would likely cover many cases. Fine tuning would be needed of course. The problem right now is that there is no standard at all, or baseline, or anything.

02:06:09
@Mark, the reporting depends on local laws (vary a lot)+ previous contracts (vary a lot). The common thing is - make a proper report according to laws + policies of the parties

02:06:38
Fair enough. We could still do better, though. We can agree on that at least, right.

02:07:26
thanks

02:07:44
That was really useful - thank you both!

02:09:27
IGOs can withdraw at any moment and we can not do anything about it

02:09:33
@Jeff - we referred to both sets of work in the paper - good stuff. The I&J approach in particular is very complimentary with what we’re proposing - they’re focused on cross-border issues, but it’s even a problem within jurisdictions. Interoperability is the key concept.

02:09:45
The need for legal advice is not definitive. The WT understands there is a process to request funds should it come to that.

02:10:03
@Marie - thanks - very glad to be having this discussion with you and hope to continue the dialogue!

02:10:31
@Rod, the issue is - usually trusted notifiers tend to be from the same jurisdiction as a registry or registrar (so complaining to existing notifiers might be another option to add to the matrix)

02:11:09
Hi Keith !

02:11:17
Hi Keith

02:11:33
@maxim very good point!

02:13:09
guidelines do not seem to be obligatory, so it is not a policy

02:14:48
@Maxim - great point on trusted notifiers - we did touch on trusted notifier programs as well as part of the solution space. They may be a very useful conduit to add efficiency, enforce standards of evidence and reporting formats, and many other things. Such entities would be natural participants in an overall discussion since they have already done a lot of work around creating their own standards that can be shared and normalized to some extent to improve the way incidents are handled.

02:15:12
From an objective perspective, most ccTLDs do not even need to be present at ICANN. And yet they are. So the institution must carry some weight. It's just not absolute.

02:15:30
@Rod, the standards are depending on jurisdictions and contracts

02:18:23
Perfectly said, Keith. #July

02:18:38
old hand

02:19:38
Thank you Keith for the update.

02:19:42
thanks

02:21:49
@Maxim - absolutely. There are really two things here. One, what things exist or could be brought into existence to be truly “universal” standards or interoperable processes. Two, where can one go to in order to find information on the particular standards and processes you need to follow within particular jurisdictions, industries, or even individual infrastructure providers? As a rough analogy. think of the the first as the base level wiring of the global network and think of the second as creating a way to properly interface disparate networks together. We don’t have either right now.

02:24:23
without a definition of what to find we might not know what to do

02:25:54
That's what the scoping team is for, Maxim.

02:25:57
Thanks Maxim & Rod for the debate, this has great academic value for us to find paths and be able to move forward.

02:28:42
@Marie, not necessary, so far it is an item for GNSO Council discussion

02:34:45
GDPR added another definition of Accuracy

02:36:04
without a definition we even do not know who the experts are

02:36:17
NIS2 is just a text now

02:36:24
not even a directive

02:36:44
and the laws following NIS2 are long in the future

02:37:12
we can not make policy adjustments for drafts of texts

02:38:52
That makes sense Kurt - thanks.

02:38:53
without a target we will have a fishing expedition without a reasonable timeline

02:40:04
like another endless PDP

02:40:36
But according to the comments from the GAC, it is irrelevant what the term accuracy means per GDPR. They are asking about accuracy under the agreements

02:40:52
it causes confusion

02:41:36
The scoping team could be asked to consider if legal advice is needed.

02:42:24
yes

02:42:33
Yes to Marie

02:42:47
As long as people are not pointing to the GDPR and insisting on “accuracy”, Jeff, sure. But it would be more empirical as an approach to look at what accuracy means under different regimes.

02:43:02
You can put me down for the small team

02:43:06
Volunteering. :-)

02:43:11
Noted!

02:43:18
Volunteering!

02:43:26
The GAC has asked for Accuracy under the contracts.....not accuracy under GDPR, NIS or anything else

02:43:47
muted?

02:44:24
@Jeff: Not in the contract but subsequent work spoke to standards and formats of data for some fields collected

02:44:31
That was the GAC's point in raising the WHOIS Accuracy Reporting System and other efforts that have been going on for years

02:44:42
I also volunteer Nathalie

02:44:58
Nathalie - I suppose I should be on the accuracy team to report to the GAC

02:44:59
The GAC is not having to pay for the process of obtaining accurate data. Non trivial issue….

02:46:09
Stephanie - this is not a debate on whether this is a good idea or bad idea. The contracts state that accurate data will be collected. That has always been in the contracts since at least 1998 (if not before).

02:46:19
And that was the GAC's point

02:46:26
with my paraphrasing

02:46:47
And I am only the messenger :)

02:46:59
Nothing from me

02:47:02
Thanks Philippe

02:47:13
@Stephanie: My reading of the GAC is a very politic advice "ICANN, you need to define and say what you mean by accuracy sufficiently in contract"

02:47:13
Thanks all

02:47:18
thx

02:47:19
Thanks all

02:47:21
Thank you all!

02:47:22
Bye for now then...

02:47:25
Thank you all, bye!

02:47:31
Thank you

02:47:33
@Carlton - yes

02:47:33
Thanks everyone, bye!

02:47:34
Thanks all

02:47:42
Bye