George Michaelson wrote on 2023-07-18 22:41:
...
my concerns with the PSL governance aren't relevant either. I am sure
it was purposeful. I don't have to like things for them to provide
upsides.
when we've tried to talk about solving the PSL's original problem
differently, we've run into th
so some TLD don't. But also some ccTLD are using notation which
probably doesn't matter much, but confuses me because it is wildcarded
ONLY where other ccTLD put both the bare TLD and the wildcard (as
noted before)
look, there's nothing to see here. my confusion is not an industry
wide problem. cc
George Michaelson wrote on 2023-07-18 17:42:
I know, I could submit these to the PSL website directly. I am asking
a meta question: do we think that operationally, if a PSL exists, that
all ccTLD and TLD should be on it?
no. as we learned from delegation-only, some TLDs don't.
i see ~36mil
On Jul 18, 2023, at 20:42, George Michaelson wrote:
>
> I know, I could submit these to the PSL website directly. I am asking
> a meta question: do we think that operationally, if a PSL exists, that
> all ccTLD and TLD should be on it?
ccTLDs are mostly general registration so probably yes. Bu
On 7/18/2023 8:42 PM, George Michaelson wrote:
I know, I could submit these to the PSL website directly. I am asking
a meta question: do we think that operationally, if a PSL exists, that
all ccTLD and TLD should be on it?
The following ccTLD are in ISO3166 but not in the PSL:
bd
bl
bq
On 7/18/23 7:42 PM, George Michaelson wrote:
I know, I could submit these to the PSL website directly. I am
asking a meta question: do we think that operationally, if a PSL
exists, that all ccTLD and TLD should be on it?
I'm of mixed opinion.
I see the value in having ccTLDs and TLDs on the P
I know, I could submit these to the PSL website directly. I am asking
a meta question: do we think that operationally, if a PSL exists, that
all ccTLD and TLD should be on it?
The following ccTLD are in ISO3166 but not in the PSL:
bd
bl
bq
ck
eh
er
fk
jm
kh
mf
mm
np
pg
um
za
all t
>> Note that Scott's current EPP draft is still using this term,
>> citing the definition in 1912. Should the term be removed
>> from Scott's draft, or acknowledged that it is now historic?
>> If Scott replaces it with another more precise term, can we
>> get that term in this document so that fut
> With the DNSOP interim meeting last June, we reworded the definition
> of "lame delegation". This new definition of "lame delegation" has
> been shared on the mailing list and included by the document authors
> in the latest revision of the rfc8499bis draft,
> https://author-tools.ietf.org/iddif
> -Original Message-
> From: DNSOP On Behalf Of k claffy
> Sent: Tuesday, July 18, 2023 12:41 AM
> To: George Michaelson
> Cc: Benno Overeinder ; DNSOP Working Group
> ; DNSOP Chairs
> Subject: [EXTERNAL] Re: [DNSOP] WGLC rfc8499bis for revised lame
> delegation definition
>
> Caution: T
On Jul 17, 2023, at 22:50, Paul Vixie wrote:
>
>
>
>> Agreed, but that horse had already left the barn when we published the first
>> SPF RFC 4408.
> RFC 4408 was folly. TXT in a subdomain (RFC 5507 s3.2) would suit domain
> verification well (wildcards aren't a factor) and would in no way b
Dne 17. 07. 23 v 21:41 Brian Dickson napsal(a):
TCP traffic is several orders of magnitude more expensive than UDP.
This might be true, but it must be carefully considered. Yes, a
performant authoritative server is able to answer (for example) 10 Mqps
over UDP or 10 kqps over TCP. One could
12 matches
Mail list logo
