<div dir="ltr"><div>Hey Jothan,</div><div><br></div><div>The OCTO-11 Document is good and important, but is lacking some impotent items such as Browsers and dependent parties.</div><div>* Browsers - E.G. (Chromium, Firefox) whoch have a good process, Safari / Edge / Samsung which is a patial Enigma or bug reporting process <br></div><div>* Dependent parties - PublicSuffixList, publicsuffix-go, LetsEncrypt</div><div><br></div><div><div>I would say that a lot of good people are trying to help but some of it have overlapping dependencies and other considerations. <br></div><div dir="ltr"><div><div dir="rtl" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="rtl" style="text-align:left"><font face="tahoma, sans-serif" color="#999999"><b><br></b></font></div></div></div></div></div></div></div></div></div></div><div>I'm still taking notes and will publish a post when i have all the data (contact channels, release time frames, addition important relaying parties, etc...)</div><div></div><br><div dir="ltr"><div><div dir="rtl" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div style="text-align:left"><font face="tahoma, sans-serif" color="#999999"><b> Thanks,</b></font></div><div dir="rtl" style="color:rgb(136,136,136);text-align:center"><font size="2"><span style="font-family:tahoma,sans-serif"><span style="color:rgb(153,153,153)"><font size="2"><b>Lavie Ben-Baruch</b> | </font></span></span></font><font size="2"><span style="font-family:tahoma,sans-serif"><span style="color:rgb(153,153,153)"><font size="2"><font size="2"><span style="font-family:tahoma,sans-serif"><span style="color:rgb(153,153,153)"><b>לביא בן-ברוך</b></span></span></font></font></span></span></font></div><div dir="rtl" style="color:rgb(136,136,136);text-align:center"><div><div style="color:rgb(136,136,136)"><div><font size="2"><span style="font-family:tahoma,sans-serif"><span style="color:rgb(153,153,153)"><span style="color:rgb(17,85,204)"> </span><a href="mailto:laviebb@isoc.org.il" style="color:rgb(17,85,204)" target="_blank">laviebb@isoc.org.il</a> | </span></span></font><span style="color:rgb(153,153,153);font-family:tahoma,sans-serif">+972-54-595-7071</span></div><div><div style="color:rgb(136,136,136)"><div><font size="2"><span style="font-family:tahoma,sans-serif"><span style="color:rgb(153,153,153)">Office | </span></span></font><span style="color:rgb(153,153,153);font-family:tahoma,sans-serif">+972-3-970-0919<br></span></div></div><span style="color:rgb(153,153,153);font-family:tahoma,sans-serif"></span></div></div></div></div><div dir="rtl" style="color:rgb(136,136,136);text-align:center"><font size="2"><span style="font-family:tahoma,sans-serif"><span style="color:rgb(153,153,153)"> איגוד האינטרנט הישראלי | </span><span style="color:rgb(153,153,153)">Israel Internet Association ISOC-IL<br></span></span></font></div><div dir="rtl" style="color:rgb(136,136,136);text-align:center"><a href="http://www.isoc.org.il/" style="font-family:tahoma,sans-serif;color:rgb(17,85,204)" target="_blank">www.isoc.org.il</a><br></div><div style="text-align:center"><div dir="rtl" style="text-align:center"><font size="2"><span style="font-family:tahoma,sans-serif"><span style="color:rgb(11,83,148)"></span></span></font><img src="http://www.isoc.org.il/wp-content/uploads/2016/04/isoc_logo-Heb-300x150.png" alt="איגוד האינטרנט הישראלי - ISOC-IL" width="200" height="100" border="0"></div><div><br></div><span style="color:rgb(11,83,148)"></span></div><span style="color:rgb(11,83,148)"></span></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 29 Aug 2022 at 12:08, Jothan Frakes <<a href="mailto:jothan@gmail.com">jothan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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 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" target="_blank">https://www.icann.org/en/system/files/files/octo-011-18may20-en.pdf</a></div><div style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div 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 style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div 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 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 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 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 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 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 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 style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div 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 style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div 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 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 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 style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div 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 style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div 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 style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">-Jothan</div></div></div>
_______________________________________________<br>
dns-operations mailing list<br>
<a href="mailto:dns-operations@lists.dns-oarc.net" target="_blank">dns-operations@lists.dns-oarc.net</a><br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
</blockquote></div></div>