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

me too

I always have to type in the password.

cut & paste worked for me.

The document we are looking at is here: 2.2.2 Predictability: https://docs.google.com/document/d/1vBckhFQCCQ-zyvfGGcDB3NWQhodVsffdqbyb6kTwXL4/edit?usp=sharing

page 4

I'm glad that Jeff is noting that RPMs is very much a part of the "changes" we are discussing.

As long as you have enough representation from the community and from the PDP working group, you should be okay but "at least one" person from the PDP WG is not at all acceptable in terms of representation.

Agree with Anne

Sorry for being late

Hi sorry for being late!

I thought we agreed last week that representation from the PDP WG was optimal, but it needs to be recognised that because of the passage of time this may not always be possible.

Yes Donna - what I am objecting to is the language that says SPIRT should have "at least one" member of the PDP WG. It should say that invitations should be broadly distributed and should go out to ALL members of the PDP WG - just as the IRT guidelines say.

Hypothetical: I hereby volunteer to serve on the SPIRT team. Who is going to say that I should or should not be a member?

@Jeff, I suppose. But what we are asking here is that the GNSO change its process and permanently delegate part of its role

@Anne, I think it would be beneficial if there is an upper limit on the number of people on the SPIRT so I don't necessarily agree that it should be an open call for members.

SPIRT will not be nearly as fully representative of the entire GNSO community as Council will be.

@Jeff - perhaps, but where does the danger lie? That the Council may accidently do implementation or that the SPIRT accidently does policy? I think it is the latter.

+20 Paul.

Thanks Donna - makes sense but how do you decide WHO gets to be a member of the SPIRT?

@Jeff: did you say you had a question for me?

@Donna - for me, yes. That would help a lot.

GNSO Council for D and E should get input from the Community!

@Jeff - but we can't reconfigure how policy is developed just because everyone is frustrated with how slow Council works. If Council is too slow, the Community can take steps to address that. Circumventing the Council is not an answer.

The biggest issue is how you determine which bucket the issue belongs in - A, B, C, D, or E - Council has to have the final say on that. but there is an issue as to how quickly Council could make that determination.

new hand

Plus, GNSO Council aside, don't forget that the Board and ICANN Org could also send things to SPIRT, isn't that so?

@Justine, yes they can, but those issues can also be Policy

Transparency and predictability is the bed rock of multistakeholderism, not efficiency (although efficiency is good where we can get it, but not at the cost of sacrificing the Council's role).

It doesn't matter where the issue comes from

@Donna, my question points to the possibility that things get sent to SPIRT without going though GNSO Council. So are you saying that in such events SPIRT has to first ask GNSO Council what it should do?

@Justine, it was a suggestion to overcome concerns by Paul and Kathy. Not sure what view I subscribe to yet.

@Donna, right. So I should pose my question to @Kathy and @Paul.

@Donna - could you repost the question?

Chat is hard!

@Donna, my question points to the possibility that things get sent to SPIRT without going though GNSO Council. So are you saying that in such events SPIRT has to first ask GNSO Council what it should do?

Thanks @Donna, @Kathy, that was my question (incorrectly) posed to Donna.

I think what Jeff says makes sense. The safety is the GNSO Council retains control over SPIRT.

Taking Staff out as a referral source to SPIRT and leaving only the Board and Council as the referral sources would also bring some comfort.

@Anne, that makes sense

The SPIRT is more than a sorting function.

But don’t forget that there are other SO/ACs out there as well

@Kathy, that was my question actually.

@Donna - please elaborate - I understand SPIRT as only making recommendations as to how to handle an issue that arises after the applications are in.

"Issues identified as C,D, and E would generally speaking, be expected to be referred to the SPIRT" => from the GNSO Council [!][chart]

@Jeff - what is the threshold for the Council to reach down and bring something up to Council? 1 Constituency? Supermajority of entire Council?

@Annebeth +1. There are other SO/ACs that are representative of the Community.

@Paul - that should be the threshold triggers in the Annexes on Input, Guidance, and EPDP. My recollection is one Council member can initiate that discussion at GNSO Council

bottom section

What is the check and balance preventing (eg) Org from framing an issue as operational and not send it to SPIRT at all?

there is no such thing as a pure policy issue in our world

I don’t want complicate this anymore , but where does the GDD slot into this . does it report into the Spirt team ?

The GNSO is the expert on policy elements

Why do we think the SPIRT is better position to parse out what is policy and what is not?

@Justine, I don't know that there is one.

@Paul, because SPIRT is more nimble and can act more quickly than GNSO Council.

@Justine - we are assuming such is the case, but the SPIRT is an experiment

Triage *is* more than mere sorting

exactly @Anne

Another possible safety net is that everything that leaves SPIRT goes to Council.

"Expediting sorting process" => good

@Anne, and to figure out solutions to recommend on issues that it is given to figure out after the triage.

*issues that are given to SPIRT to figure out after the triage exercise

+1 Anne

How is an accountability mechanism more efficient than just having Council sort policy from implementation at the outset?

We can make some annotations to go with the flow chart

Paul - because Council is too slow and public comment said "We want a Standing IRT".

sorry for being late, other conf call just ended

Welcome @Maxim

Did you send this out to us? It's very helpful. But the flow chart is still wrong if it implies staff can decide the A & B bucket or that SPIRT can decide a policy issue.

Issue - If I volunteer to serve on SPIRT - who decides whether or not I do serve?

See the document at: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQLuQuo/edit?usp=sharing

Quick process question Jeff. Hand up.

Justine proposed adding footnote 2

the rationale she provided for this change is included in the comments

“Proposed change does not impact rationale but instead adds necessary clarity by addressing omission of a dependency to the Role of Application Comment section.”

Were trying to get to Recommendations Language Yes @Paul

We would need to *STATE* ""Consensus Call"" for it to be one @Paul

@Chery - will the Consensus Call come section by section?

No ypur not @Paul

@Jeff is saying we are hopefully not going to get too many suproses FROM the C Call

The LT has not actually decided that yet @Anne with Large Works that is often my personal preference however, but not able to answer that yet... Will do hwever

I thought this was just short of the finish line and certainly those that have been participating in this process should be pretty comfortable with the recommendations.

@Donna, so did I, so did I.

We would hope do @Donna

I think Paul makes a good point that feedback from our constituencies was not what we were contemplating at this phase of drafting

I consider the feedback from constituencies/community to be a separate effort. The public comment period is an opportunity to hear from those not closely involved in the day-to-day of this WG.

I am a little confused here. I have always thought that when we are doing a consensus call, it is the total we are discussing, can we accept consensus. Here we are talking about specific things we should flag that are really problematic for us. Have I misunderstood completely?

why did we need veto rights for outside of GNSO bodies?

@Annebeth - agree. Consensus calls are meant to look at the entire package. It appears, now, that this "can't live with" process is meant to accelerate the consensus call process at a recommendation by recommendation level.

But, I don't think this is proper.

I think most of the Package proposals submitted are meant to address omissions, small errors, things to clarify - that sort of thing. Can those who have submitted Package forms confirm or deny this?

+1 Anne.

@Paul, I have seen this as an opportunity to flag an issue that is really unacceptable and an opportunity to offer an alternative

Justine- I think there are substantive changes in the comments made.

Rationale provided by Justine: "1. Since insufficient awareness of the Program prior to the last round is well acknowledged, this ImplementationGuidance ought to prescribe – not merely suggest – a minimum time period for the next round’s Communications Period. 2. Prior WG discussion on the distinction between the terms “must” and “should” and when either ought to be used, applies."

Is this helpful: https://tools.ietf.org/html/rfc2119

I would support Justine’s request to change “should” to “must,” otherwise it’s possible the communication period could be truncated for any number of reasons. I also agree with Anne that we need clarity on the definitions of each word.

@Paul, that is unacceptable.

should has been the consistent use to date

NEXT CALL:Thursday, 28 May 2020 at 20:00 UTC for 90 minutes

@Paul .. are there other ways to prevent ICANN from holding up the start of subsequent procedures thought?

"should" does not achieve the public communication goal unless "should" has a LOT of "umph"

The IETF has definitions that may be helpful: https://tools.ietf.org/html/rfc2119

lots of important discourse today people Thank You All!! Bye for now...

@Anne, can you think of an alternative that gives the requisite ooomph?

bye all

bye all