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

[Meir Kraushar via dns-operations]

--- Begin Message ---
Hi kim
Launching this IDN TLD was actually the first time we created a new TLD
(well, besides the cctld we already maintain from long ago). For a small
registry like ours, it is something  you will probably never practice. So
frankly, no one here knew that the PSL ever existed, until we were cought
in a bind. Even then, it took us a lot of googling and time to come across
some relevant information, and finally to realize the existance of PSL, to
our embarrassment. When that happened it was already too late, we had to
postpone the new TLD launch.
As the DNS guy we did everything. All required procedures with ICANN and
IANA. But then we found out that there is this "little thing" with browsers.
I think it's important to prevent such a mishap from happening again.
My experience with IANA is such that when something matters and is
important, you know how to make it very clear to us registries.  I was not
suggesting automation or synchronization with Mozilla, that of course is
complicated.
But for example  a remark in the rzm site, a reference to the documentation
would have emphasized the PSL stage, would have put
 that info in front of us.
Meir

On Mon, Aug 29, 2022, 03:05 Kim Davies  wrote:

> Hi Jothan,
>
> Quoting Jothan Frakes on Saturday August 27, 2022:
> > 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.
>
> 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. The impression I came away with was the PSL guarded
> its independence and therefore there wasn't a role for IANA. 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
>
> If PSL is still not automatically recognizing new TLDs, 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.
>
> kim
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

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

[Lavie B.B. via dns-operations]

--- Begin Message ---
Hey Jothan,

The OCTO-11 Document is good and important, but is lacking some impotent
items such as Browsers and dependent parties.
* Browsers - E.G. (Chromium, Firefox) whoch have a good process, Safari /
Edge / Samsung which is a patial Enigma or bug reporting process
* Dependent parties - PublicSuffixList, publicsuffix-go, LetsEncrypt

I would say that a lot of good people are trying to help but some of it
have overlapping dependencies and other considerations.

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

*   Thanks,*
*Lavie Ben-Baruch* | *לביא בן-ברוך*
 lavi...@isoc.org.il   |   +972-54-595-7071
Office   |   +972-3-970-0919
 איגוד האינטרנט הישראלי  | Israel Internet Association ISOC-IL
www.isoc.org.il
[image: איגוד האינטרנט הישראלי - ISOC-IL]



On Mon, 29 Aug 2022 at 12:08, Jothan Frakes  wrote:

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

Re: [dns-operations] Browser Public suffixes list

[Stephane Bortzmeyer]

On Fri, Aug 26, 2022 at 10:25:49PM +,
 Paul Hoffman  wrote 
 a message of 100 lines which said:

> There's also, you know, the DNS itself

Speaking of DNS, it is time to remind readers that there was a
project to express information such as "is it a public suffix?" in
the DNS and it failed:

https://mailarchive.ietf.org/arch/msg/dbound/F9SkNAZmYHGKlRwbn5Il78pOkFs/
https://datatracker.ietf.org/wg/dbound/about
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [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


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