[dns-operations] [Ext] Re: Browser Public suffixes list

[Jothan Frakes]

> > I am really frustrated that the materials developed for IANA to share to
> > avoid things like this were not distributed, as awareness would have led
> to
> > earlier request, which in turn would have diminished the propagation
> timing
> > gap with the browser side.
>
> I'll confess to being quite perplexed because it sounds like IANA has
> dropped the ball, but I am at a loss as to what IANA materials you
> are referring to. I am not aware of any materials developed for IANA
> to distribute, and we don't have an existing practice of relaying
> information about third party projects to TLD managers. Apologies if
> I've completely overlooked something.
>

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"
https://www.icann.org/en/system/files/files/octo-011-18may20-en.pdf

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.

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."

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.


> I know you and I have had discussions in years past about other TLDs
> that were missing from the PSL, and I've asked if there were ways IANA
> could contribute.


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


> The impression I came away with was the PSL guarded
> its independence and therefore there wasn't a role for IANA.


The development community have demonstrated their wants as light-touch,
sans bureaucratic things, and free-license with no obligations

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.


> In light of
> that I'd shared with you some sample code that I felt could immediately
> be used by the PSL maintainers to identify gaps, or built upon to
> trigger additions in your workflow:
>
>     https://gist.github.com/kjd/3b1141451c77e50e0ab1120caac40072


Thanks for that - it was appreciated, and running it happens when cycles
available, manually.


> If PSL is still not automatically recognizing new TLDs,


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
https://github.com/publicsuffix/list/issues/1325
<https://github.com/publicsuffix/list/issues/1325>

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.

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.


I would suggest
> it would still be a better approach to automate rather than putting
> the burden on each and every TLD manager to manually request to be
> added. After all, the underlying truth of a TLD's existence is easily
> ascertainable with existing tools without adding extraneous workflow
> steps.
>

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.

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.

 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.

-Jothan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20220829/81abfd21/attachment.html>