051040040 New gTLD Subsequent Procedures Working Group call - Shared screen with speaker view
Laxmi Prasad Yadav
Please review ICANN Expected Standards of Behavior here: https://www.icann.org/resources/pages/expected-standards-2016-06-28-en
at 0200 you don't want to see too much more of me I made an early cameo appearance before we started recording... really that will do...
Yes, Monday 23 November at 20:00 UTC
What Donna is saying makes sense - personal view.
Noted Flip we can include that in what we send t the list as well
good point Jeff
My take is that an applicant could change from a named RSP to "will use a pre-approved RSP". It would be an applicant change request but with a strong presumption of approval.
Would Applicant check a box - e.g. keep RSP confidential?
an 'if they so desire' option to identify then @Donna?
That is interesting Donna
Interesting thoughts, Donna
Is there anything that would prevent an applicant from simply naming a pre-evaluated RSP without actually having contracted the RSP in advance of its application?
and that did happen in 2012, I just don't recall the details of the process
Now you can hire Jeff to do the negotiating for you
thanks @jim for the commercial
I wouldn't put too much weight into having an agreement with an RSP as an intent to operate. When you operate an agreeemtn for one or 2 strings, maybe but when its for 10, 20 50 or 200, its a one time deal.
My recollection is the same as Jeff's.
But we also recommend RST focusing on actual testing instead of assessing documents.
The reference to “5. Article 19” needs clarification. There has been more than one Article 19 on the Internet.
is it meant to relieve applicants from having to go through PDT multiple times or RSPs from having to go through it multiple times?
RST has some per-string tests like DNS that indeed have to be done each time.
Judgement call by who Alan?
aspects is a good term @Alan
Thanks @Martin noted
Good point @ Martin
So if PDT is required the RSP will need to be known at the time of submitting the application in order to complete the evaluation process, no?
PDT is after contracting.
But if new evaluation criteria appears, that could lead to an update of pre-evaluation.
Not in a position to speak today.
Nothing in the middle.
I agree with Jeff.
Jeff is a big nerd.
ICANN Org also suggested ditching scores in its own assessment.
Comfortable with this being IG
Not from me either
This comment on CQ is not surprising, but the difference between their instance and the community one is well established.
I agree Jeff .
Agree with Jeff and Phil.
on clarifying questions: ICANN should have the discretion to redact information they consider confidential. I think the intent of the publishing the CQs was transparency and potentially giving other applicants a 'heads up'
We established that national law would base whether such certification is binding.
Are there any other point people want to discuss from the input we got on this topic?
It covers DNSSEC signature of the zone, but does not cover acceptance of DNSSEC signatures from registrars.
Because it doesn't test EPP at all.
your so quick @Rubens … Thanks :-)
Can Jeff get some praise for this call? He knows this stuff cold. Great job guiding this tech heavy discussion Jeff.
+1 Paul, impressive!
so we need to start looking to developing final text for our report this will be an ongoing need of homework from now on... so you can raise issues to the list and of course in calls (we will make a short Agenda item to allow any such issues to be elevated to the record for notice
An idea on PDT: perhaps it be done on a timeline basis that provides that an RSP is only required to submit to testing no more than once every three months and this will be decided by the PDT queue.
+1 Paul, Jeff impresses me. (Not only today!)
Donna, for per-string tests that wouldn't cut it.
I would welcome clarity on what PDT is to encompass.
Will review it.
thx all !
Thanks all, and have a nice weekend! Stay healthy!