Andrea Glandon's Personal Meeting Room
I have a question about the document sent “Recommendations for the Technical Utilization of the Root Zone Label Generation Rules 1.2”
it has text referencing to be ‘community developed’ a lot, and is was not a product of a proper PDP process
and it is bit misleading
policy can not be updated prior to the Policy Development Process
This is the email on the screen: https://mm.icann.org/pipermail/gnso-council-idn-scoping/2019-October/000038.html
Michele Neylon sends his apology for this call.
@Maxim, what are in the two phases in your mind?
I think we need to find parts which are not dependent one on another, for example purely technical/linguistic (as character tables based on linguistic studies) and tech/operational/legal (where we have prohibitions, what allowed, how to couple variants domains/strings, who prevails, what to do with applied to strings if something is wrong from perspective of char tables or varian ideas)
it should be named so (or linguistic experts community), not the whole community
it is not a policy, but internal ICANN process
and it can not change policies
history of things is not important from the legal perspective, might be useful for understanding of initial ideas and to ensure they are still actual/followed in the process
and about purely legal experts/Tech part - if we see that it is not necessary , then we have only one phase , where linguistic/tech/operational/legal things are all together
because it is not possible to separate operational and legal sides
Please note Steve has hand up too
@Edmon, hand up as well
like RPMs PDP and SubPro PDP do (substreams)
but Registries and Registrars have to follow RFCs created in IETF
so it might happen
I agree with Steve. The reason the Council created this group is to be able to rely on the “expert” to scope the PDP.
I think some more SGs would like to participate in the chartering team
Could we start calling Root Zone LGR as RLGR and second level as just LGR?
to avoid further confusion
Just want to note that the scoping team had earlier discussion about the IDN guidelines, and they are documented toward the end of the document here: https://docs.google.com/document/d/1o_9bfnkKufrSxiJGxpNcOcfTK2VLWp5XYQvwe5qxJlc/edit#heading=h.4l14uuzc4nrt
or RLGR and SLGR
Root zone LGR will affect Applicants and Registries, Registrars and Registrants, the same for Second level
I would re-phrase what i said earlier…it’s not necessarily about a narrow scope, but make the scope only as wide as it needs to be. I know that’s pretty obvious on the surface, but it’s easy to end up with a bloated scope (see SubPro)
SubPro is about what was not ok in the 2012 round, and it was a lot
so there is no simple solution for complex set of issues
Can i steal about 5 minutes for AOB?
no EPDP please
Why not Maxim?
what is the reason to avoid the first step?
EPDP is different from PDP as it does not have an Issue Report
It does not need to have a ‘constrained’ timeline like the one for temp specs
But what is your reasoning against an EPDP Maxim?
Agree with Maxim, SubPro does not make sense to me. SubPro is about future TLDs, and the Variant TLD policy will impact existing TLDs (i.e. existing contracts)
it is for the Council to decide
the set of documents is not perfect , should not be used , not holistic and does not cover concerns of SGs
but if the issues report is produced by staff the same non holistic concerns would arise would it not maxim? :-P
depends on the text
and as I wrote - it is up to the whole GNSO Council
cross liaisons between ccNSO - GNSO?
I need 30 seconds
great, thanks. we will include this as a topic on the October Council meeting
we have time till 14oct?
I meant next meeting
24 oct - GNSO council , and docs need to be provided 10 days earlier
or better 11
03:00 i believe
have to leave now. Bye
coudl we make doodle poll for times dates?
bye all and thanks
Thanks Edmon and all