> On 11 Apr 2022, at 17:57, Mark Andrews wrote:
>
> I don’t see why APL (RFC 3123) can’t be used for CRC give you need to
> construct an
> owner name anyway and have well known label to seperate the components of the
> name.
> I see no reason to re-invent the wheel here.
>
>
Andrew Sullivan wrote:
> I tried to document this ages ago in
>
https://datatracker.ietf.org/doc/draft-ietf-dnsop-reverse-mapping-considerations/,
> and got so many contradictory edits (see the history) that the final
> version ended up saying “A or maybe not-A, or maybe both,
On 21:24 07/04, Dick Franks wrote:
> On Thu, 7 Apr 2022 at 19:44, Joe Abley wrote:
> >
> > On Apr 7, 2022, at 21:10, Paul Vixie
> > wrote:
> >
> > > but it seems to me you'd be better off with a zero-length option called
> > > SERIAL which if set in the query causes the SOA of the answer's
I tried to document this ages ago in
https://datatracker.ietf.org/doc/draft-ietf-dnsop-reverse-mapping-considerations/,
and got so many contradictory edits (see the history) that the final version
ended up saying “A or maybe not-A, or maybe both, your choice,” so the
then-chairs decided the
Hi, in reviews of
https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-iot-dns-considerations-04.html
I was asked to expand upon why the reverse map can not be intelligently used
for MUD ACLs. (section 3, XXX stuff)
(MUD controllers, upon being presented with ACLs made up of
names need to
> On 11 Apr 2022, at 14:01, Masataka Ohta
> wrote:
>
> I can't see any as discussion is still ongoing.
There is no discussion, just you arguing with yourself. Please stop.
___
DNSOP mailing list
DNSOP@ietf.org
On Mon, 11 Apr 2022, Masataka Ohta wrote:
I can't see any reason why you think the root zone is
more secure than TLDs, especially because, as I wrote:
Because I am informed about their operational procedures and I
contributed to the technical design as one of the for the DNS Root Zone
Paul Wouters wrote:
In your
favourite terms, diginotar as DNSSEC entity would have only
been able to mess up .nl and not any other TLD, if it had been
a "DNSSEC CA" instead of a "webpki CA". The hierarchical space
offers better security than the flat webpki.
I can't see any reason why you
Paul Wouters wrote:
First, "CA" is terminology not specific to WebPKI, whatever it
means, but PKI in general including DNS. That is, a DNSSEC TLD is a
CA.
This is incorrect.
First, thank you very much for an evidence that discussion is
still continuing.
Anyway,
I'm against the proposals from Ohta-san.
/Jerry
On 4/11/22 15:01, Masataka Ohta wrote:
Paul Hoffman wrote:
I see a very strong consensus in this thread against the proposals
from Ohta-san,
I can't see any as discussion is still ongoing.
Masataka Ohta
Paul Hoffman wrote:
I see a very strong consensus in this thread against the proposals
from Ohta-san,
I can't see any as discussion is still ongoing.
Masataka Ohta
___
DNSOP mailing list
On Mon, 11 Apr 2022, zhangcuiling wrote:
And the main purpose is to improve the diversity of DNSSEC algorithms, and to
make it convenient for people who want to use SM2
digital signature algorithm as an alternative for DNSSEC.
We actually want to prevent as much diversity as we can, to avoid
I don’t see why APL (RFC 3123) can’t be used for CRC give you need to construct
an
owner name anyway and have well known label to seperate the components of the
name.
I see no reason to re-invent the wheel here.
ftp.foo.com_21_bar.com,195.13.35.0/24,91.220.43.0/24
would be
13 matches
Mail list logo
