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

Our meetings next week are back-to-back on Tuesday - in Hamburg time.

https://docs.google.com/document/d/1qjiKBaAAMNPctSIwP932OKT6vrgkFXxdVYVf6DAz2no/edit

I still think “enforceable”is better since “effective” would be a subjective measure.

I would propose to stop at “that” as it is completely redundant

Agree with Michael. I would delete effective. That's totally subjective.

I like both.

I don't care about A or B version but I do not support the word "effective".

@Brian — Agree — drop the text after second “that”

@Brian — Agree — drop the text after second “that”

agree with Phil

I prefer Option A

I also like option A

Otherwise, and regardless — Option A

that was what I sent on the list that was supported (dripping at “that”)

effective = somehow measured and later regarded as good, so it does not work before something happen

I'm fine with A

Good by me

A

A is fine with me too

@Maxim — Agree as to "effective"

As I am agnostic, A is OK. :)

A is slightly better

+1 for A

A - seems fine

toss a coin?

Yes to A

Yes that was the reason for including it

I agree that it’s implied without the added part that the policy is enforceable, but the latter part is intended to confirm that it is the Provider specifically who would enforce (as opposed to ICANN or something else)

Can we see URS Rec #9 too?

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

@Kathy: #9 and Proposal #34 are combined.

No, they're not

(sorry, but true)

I thought we had reached agreement last meeting to go ahead with the combined 9 and 34 and were just working on refinements to the language to be included

I think 'may not' is also prohibitive in this context

@Kathy: This was the action item from the last meeting: ACTION ITEM: Staff will revise the language of the combined Recommendation #9 and converted URS Individual Proposal #34 based on the WG discussion during the meeting on 06 October and circulate it to the WG list for review; staff also will consult with Renee Fossum from FORUM.

@Griffin: That is the staff’s understanding.

but 'must' and 'should' would also work

Comments form Renee: https://mm.icann.org/pipermail/gnso-rpm-wg/2020-October/004574.html

This is NOT supplanting Rec 9… Rec 9 is being folded into this proposal which has achieved overwhelming support

@Griffin: Yes, that was the intent of the WG.

I would strike the 4th and 5th bullets -- again, these languages are likely to have nothing to do with the registrant / registration agreement (e.g., if someone from China registers a ".com" DN, they may very well use a Chinese RA, and the location of Verisign is not helpful, and only risks adding confusion); put another way, the URS itself and the Recommendation Kathy is speaking about risk confusing the parties and panel and harming due process

@Kathy: The WG agreed at the last meeting to combine Rec #9 with Individual Proposal #34.

Only if we found out that Indivd Proposal #34 made any sense... which it does not.

The WG agreed in its discussions that the two recommendation are complimentary

*complementary

as far as a provider not inquiring, frankly, this is administratively convenient, and does nothing to assist due process

Nobody is doing this bc we are proposing a new standard.......

We discussed this at length last meeting

And why are we imposing it.

Not something I think that we bargained for in a "individual proposal.:

If the complainant identifies the language of proceeding in its submission would the panelist not be able to rely on that, subject to its discretion to find that another language should be used?

That is how it is done with a UDRP

Could the provider not check the registrar website to see the agreement as identified by the Complainant to confirm?

If the Provider needs to verify the language with the Registrar, then so be it, frankly doesn’t seem like a problem since they would be verifying registrant identity details anyway

shouldn't the IRT guidance be to the Examiner, not the provider?

I think it is...

I think the draft uses the term Panel but perhaps it should say examiner

Can Staff show us agreed URS Rec #9?

Showing URS Rec 9 on screen: https://docs.google.com/document/d/1huKNcgg3VAk95oybb-7u9papLZ4kEMUHNQNElMPWMFY/edit#

+1 @ Phil

Tx Ariel. Reviewed and accepted, right?

@Kathy: The WG reviewed and accepted the language for #9 and also found in that discussion that it was not inconsistent with Individual Proposal #34.

That does not mean that with further discussion the WG could identify inconsistencies.

Contingent on finding out whether it changed the way URS Providers - which it does.

*couldn’t

Renee is there any reason why you have to get the registrant contact info from the registry? could you approach the registrar instead, so you are verifying the language and getting the data at the same time?

In what language would a notice sent to me here in Switzerland be in?

It seems easier to me for a provider to determine/verify the language of the registration agreement in a given case versus having to figure out what the proper “predominant language” is

@All: We could incorporate the input from Forum into the context.

Whatever the result, I like the idea, Julie, that IRT see Forum comments on how things work at present

I’m sorry but I am quite certain that last meeting we already agreed as a WG to move forward with Proposal 34 integrating Rec 9

I don’t understand why now Kathy is suddenly suggesting we roll that agreement back

That seems totally inappropriate to me

@Griffin: I raised last week that URS Providers don't know the language of the registrawtion agreement. It's true.

@kathy - and they can ascertain it

If they ask

We accepted URS Rec #9; Griffin there seem to be any number of barriers to this Indiv Proposal. How does overhauling an existing process help us?

Because a bright line rule of what the default language is is preferable to a wishy-washy test of various factors for deciding what the language should be

hand up

@kathy the only barrier is that URS providers would need to verify the registration agreement language with the registrar

Note: our Rec #9 was implementation guidance; this is phrased as a full-scale recommendation. I don't see the support for it.

And not really a barrier bc they could do it

@Kathy there was pretty substantial support last meeting for this approach

… depending on our confirming the underlying assumption which turned out to be incorrect...

The assumption was that the registration agreement language could be ascertained, which it can

@Ariel: Thank you. The Action was to consult with Forum and to pass that on to the WG.

I suggest a strong invitation to participate on list if this has to be continued. Strong use of list could set this up for ten minutes or less at a meeting after the list distills the arguments

Agree that this needs to be registrant centric.

And not too convoluted.

I would delete all of the opening language... and jump to Implementation Guidance.

I have a schedule conflict and have to leave a bit early. Thanks Phil, staff, and all

VA should stay blue. or at least purple.

Sorry, ignore.

If we do not make a recommendation - will it change ALP?

hand up

we do not insist for full exchange transparency to the third parties, but for the particular applicant at least

then it will be resolved via a scandal in GAC

Perhaps context of a long list of concerns raised to the WG?

My organization does not have a position on ALP. I would have to defer to experts in the process.

cities usually have good relations with telecom ministries (of whom GAC mostly consists)

IRT will have IT experts, Registries, Registrars and ICANN so it will be able to assess and correct the process

and it means that the current ALP documents were not tested

at the initial application 2012 phase

to apply for ALP with 2013 set of documents in 2012 there is a need of a time machine

hand up

should it be a request for review and correction?

2013 was very much in application phase

We are caught between a rock and hard place if we suggest implementation language we are told it may be too restrictive under certain scenarios, if we suggest policy language to achieve a predictable transparent process we run the risk of being too vague. / are told it is too vague. I think I am beginning to understand how the ALP applicants felt.

+1 Paul

Excellent point Paul. Sort of ICANN in a nutshell.

Contract language with either too much or too little bite.

29MAR2012 was the last day to submit the application

so ALP texts from 2013 were not ready

Phil's suggestion makes sense to me.

@Maxim: Yes, and staff noted that. But they have been available since 2013.

so it was too late for applicants for evaluation

Yes, that was true in 2012 Maxim, but not true since then.

before the closure of the application window

I have another call now. Have a nice evening everyone.

all applications were made before 2013, so having good documents in 2013 was too late for applicants to assess and use it at the moment of application

@Greg S.: But staff’s point is that there currently is a published process. And no indication of what is wrong with the current process.

there are no indications that the current process was good, in contrary - public comments shown it was not

thanks all

Bye All - tx to Phil for chairing!

See you in Hamburg

Thanks All

thanks Phil, bye all

thx Phil