<div dir="ltr"><div dir="ltr"></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> I am really frustrated that the materials developed for IANA to share to<br>
> avoid things like this were not distributed, as awareness would have led to<br>
> earlier request, which in turn would have diminished the propagation timing<br>
> gap with the browser side.<br>
<br>
I'll confess to being quite perplexed because it sounds like IANA has<br>
dropped the ball, but I am at a loss as to what IANA materials you<br>
are referring to. I am not aware of any materials developed for IANA<br>
to distribute, and we don't have an existing practice of relaying<br>
information about third party projects to TLD managers. Apologies if<br>
I've completely overlooked something.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">Apologies, Kim, you didn't overlook something.  I didn't mean to infer that IANA didn't do something they should have done here, but rather the document that was developed would have proactively helped the situation.  It resulted in OCTO-11 "The Public Suffix List:
A Guide for TLD
Administrators" <a href="https://www.icann.org/en/system/files/files/octo-011-18may20-en.pdf">https://www.icann.org/en/system/files/files/octo-011-18may20-en.pdf</a></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">I scrolled back through my email to May of 2020 when I was collaborating with OCTO and completed the materials with them.  Although I was pushing a bit for these to be distributed by the IANA to ccTLDs to meet the requirements of Recommendation 3 of SAC-070 on ICANN's side, now that I scroll through it, I notice I was informed by them at the time that the IANA would not be distributing anything as a result of that work.<br><br>The exact phrasing from SAC-070, Rec 3 was, "Recommendation 3: To close the knowledge gap between registries and popular
PSL maintainers, ICANN and the Mozilla Foundation should collaboratively create
informational material that can be given to TLD registry operators about the
Mozilla PSL."</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">I've often seen where advisory committees produce recommendations or advice that have to become workstream or other activities, and I get that ICANN != IANA or ccTLD obligations necessarily, but it made sense to have ccTLDs that light up into the root getting some information to help understand some of the unknown unknowns.</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)"><span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"> </span></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I know you and I have had discussions in years past about other TLDs<br>
that were missing from the PSL, and I've asked if there were ways IANA<br>
could contribute. </blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">Yes, I completely appreciate that.  As you know, the PSL has no budget or funding and is entirely volunteer maintained, so these conversations are typically hallway flyby</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The impression I came away with was the PSL guarded<br>
its independence and therefore there wasn't a role for IANA. </blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">The development community have demonstrated their wants as light-touch, sans bureaucratic things, and free-license with no obligations</div><br></div><div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">The requested role for IANA would be to manage and collect subspaces directly for ccTLDs in the interactions with ccTLD administrators and then publish something that could override those that the PSL was created initially to address.  There is no other org with those direct relationships that would be more trusted, and the PSL being relied upon in performing that role could be sunsetted with something better and more appropriate and trusted.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In light of<br>
that I'd shared with you some sample code that I felt could immediately<br>
be used by the PSL maintainers to identify gaps, or built upon to<br>
trigger additions in your workflow:<br>
<br>
    <a href="https://gist.github.com/kjd/3b1141451c77e50e0ab1120caac40072" rel="noreferrer" target="_blank">https://gist.github.com/kjd/3b1141451c77e50e0ab1120caac40072</a></blockquote><div><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">Thanks for that - it was appreciated, and running it happens when cycles available, manually.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If PSL is still not automatically recognizing new TLDs, </blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">We have automation tied to the json file that ICANN publishes when nTLD contracting occurs, but that json does not include ccTLDs, and the automation does not currently parse the tlds.txt from IANA, although there is a request from our community of volunteers to update the automation in <a href="https://github.com/publicsuffix/list/issues/1325" target="_blank">https://github.com/publicsuffix/list/issues/1325 </a></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">You'll note that I said nTLD contracting entries rather than delegated strings in describing the json.  Contracting time on gTLDs was a better trigger time for a PSL entry to be added, as it would be in advance of the TLD being included in the root.  This helped to bridge the browser propagation delays a bit, as a PSL entry would have baked into the downstream by the time it lit up.    </div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">Problems experienced by the ISOC on this one typically are result from the lack of the advance notice for proactive addition on the PSL side, and due to the infrequency of new introductions, the rate of occurrence is low - and only a problem when a new ccTLD or IDN ccTLD gets added to the root. </div></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I would suggest<br>
it would still be a better approach to automate rather than putting<br>
the burden on each and every TLD manager to manually request to be<br>
added. After all, the underlying truth of a TLD's existence is easily<br>
ascertainable with existing tools without adding extraneous workflow<br>
steps.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">Not disagreeing at all on the automation perhaps being beneficial, as we're running long on requests because the volunteer cycles are our only fuel so it lets us do more, faster and accurately.   Utopia would be that entries are always being directed by the ccTLD administrator, so that it is representative of their intentional behaviour for their TLD being expressed.</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">I'll also note that automation would have not been a solution for ISOC's issue due to the presence of the stub zones, despite any of the existing tools, no automation nor existing tools could have divined the four stub zones from the minds of the administrators.</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)"> I still think that sharing a link to OCTO-11 "The Public Suffix List:
A Guide for TLD
Administrators" or at least a mention of the PSL would be beneficial to consider distributing to whatever new ccTLDs or IDN ccTLDs get added to the root.  <br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">-Jothan</div></div></div>