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

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

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?

I would leave it to the WG to determine a timeline after convening

Is there super urgency needing the 12 month limit?

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.

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

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.

Also <note>

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

I will find that letter and post it.

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

“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.)

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.

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

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

Page 7

topic 25

Letter F of that topic

@Jeff thanks for the pinpoint

so it will be up to the WG of IDN ePDP

Subject to Council approval I would assume

So if the group comes back and says 5 years?

Many thanks to the Charter Drafting Team!

Thank you Pam!

Thanks, Kurt

We will be sure to have a more fullsome discussion as soon as possible.

Nice job Dennis

+1

Thank you Kurt, Maxim

without inclusion of ccTLDs it will not be universal

@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.

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?

(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?

@Mark , each ccTLD has own ideas

Exactly

and they will not be happy to follow

so no

The best we can hope is that a strong ICANN position would have a cascade effect

Point to a set of norms that are the industry standard

Which is why I still believe this is very worth our time

this seems to be quite optimistic

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

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.

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?

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.

@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.

SIRT = Security Incident Response Team :-)

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

since laws worldwide are different - there might not be a unified way at all

Not from the legal side, but from the procedure side they can probably be approximated

evidentiary standards vary per jurisdiction (in criminal laws)

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

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

@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.

@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

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

thanks

That was really useful - thank you both!

IGOs can withdraw at any moment and we can not do anything about it

@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.

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

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

@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)

Hi Keith !

Hi Keith

@maxim very good point!

guidelines do not seem to be obligatory, so it is not a policy

@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.

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.

@Rod, the standards are depending on jurisdictions and contracts

Perfectly said, Keith. #July

old hand

Thank you Keith for the update.

thanks

@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.

without a definition of what to find we might not know what to do

That's what the scoping team is for, Maxim.

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

@Marie, not necessary, so far it is an item for GNSO Council discussion

GDPR added another definition of Accuracy

without a definition we even do not know who the experts are

NIS2 is just a text now

not even a directive

and the laws following NIS2 are long in the future

we can not make policy adjustments for drafts of texts

That makes sense Kurt - thanks.

without a target we will have a fishing expedition without a reasonable timeline

like another endless PDP

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

it causes confusion

The scoping team could be asked to consider if legal advice is needed.

yes

Yes to Marie

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.

You can put me down for the small team

Volunteering. :-)

Noted!

Volunteering!

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

muted?

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

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

I also volunteer Nathalie

Nathalie - I suppose I should be on the accuracy team to report to the GAC

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

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).

And that was the GAC's point

with my paraphrasing

And I am only the messenger :)

Nothing from me

Thanks Philippe

@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"

Thanks all

thx

Thanks all

Thank you all!

Bye for now then...

Thank you all, bye!

Thank you

@Carlton - yes

Thanks everyone, bye!

Thanks all

Bye