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

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

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

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

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

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

34:04
I like both.

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

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

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

34:39
agree with Phil

34:45
I prefer Option A

34:58
I also like option A

35:02
Otherwise, and regardless — Option A

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

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

35:11
I'm fine with A

35:20
Good by me

35:21
A

35:22
A is fine with me too

35:24
@Maxim — Agree as to "effective"

35:26
As I am agnostic, A is OK. :)

35:27
A is slightly better

35:40
+1 for A

35:45
A - seems fine

35:52
toss a coin?

36:00
Yes to A

37:10
Yes that was the reason for including it

37:54
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)

39:06
Can we see URS Rec #9 too?

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

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

40:05
No, they're not

40:11
(sorry, but true)

40:48
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

41:08
I think 'may not' is also prohibitive in this context

41:12
@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.

41:41
@Griffin: That is the staff’s understanding.

41:59
but 'must' and 'should' would also work

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

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

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

44:47
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

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

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

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

46:59
*complementary

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

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

49:04
We discussed this at length last meeting

50:17
And why are we imposing it.

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

51:04
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?

51:21
That is how it is done with a UDRP

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

53:15
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

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

54:37
I think it is...

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

55:01
Can Staff show us agreed URS Rec #9?

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

55:34
+1 @ Phil

55:58
Tx Ariel. Reviewed and accepted, right?

56:52
@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.

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

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

58:02
*couldn’t

58:02
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?

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

59:41
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

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

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

01:01:59
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

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

01:02:20
That seems totally inappropriate to me

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

01:03:36
@kathy - and they can ascertain it

01:03:51
If they ask

01:04:19
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?

01:04:57
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

01:05:03
hand up

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

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

01:05:43
And not really a barrier bc they could do it

01:06:14
@Kathy there was pretty substantial support last meeting for this approach

01:06:38
… depending on our confirming the underlying assumption which turned out to be incorrect...

01:07:27
The assumption was that the registration agreement language could be ascertained, which it can

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

01:08:03
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

01:11:11
Agree that this needs to be registrant centric.

01:11:27
And not too convoluted.

01:11:30
I would delete all of the opening language... and jump to Implementation Guidance.

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

01:15:15
VA should stay blue. or at least purple.

01:15:26
Sorry, ignore.

01:16:38
If we do not make a recommendation - will it change ALP?

01:17:33
hand up

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

01:19:17
then it will be resolved via a scandal in GAC

01:19:33
Perhaps context of a long list of concerns raised to the WG?

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

01:19:52
cities usually have good relations with telecom ministries (of whom GAC mostly consists)

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

01:21:39
and it means that the current ALP documents were not tested

01:22:01
at the initial application 2012 phase

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

01:23:10
hand up

01:23:46
should it be a request for review and correction?

01:23:54
2013 was very much in application phase

01:24:38
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.

01:24:51
+1 Paul

01:25:15
Excellent point Paul. Sort of ICANN in a nutshell.

01:25:32
Contract language with either too much or too little bite.

01:25:42
29MAR2012 was the last day to submit the application

01:25:51
so ALP texts from 2013 were not ready

01:26:54
Phil's suggestion makes sense to me.

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

01:27:16
so it was too late for applicants for evaluation

01:27:35
Yes, that was true in 2012 Maxim, but not true since then.

01:27:36
before the closure of the application window

01:27:38
I have another call now. Have a nice evening everyone.

01:28:34
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

01:28:41
@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.

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

01:29:50
thanks all

01:29:57
Bye All - tx to Phil for chairing!

01:30:00
See you in Hamburg

01:30:16
Thanks All

01:30:25
thanks Phil, bye all

01:30:25
thx Phil