Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

On Sun, 19 Jul 2020, Paul Vixie wrote: On Sunday, 19 July 2020 07:52:39 UTC Ondřej Surý wrote: I just want to point out, that I am certainly not overthinking this with my implementors hat. The RFC and code-point puts pressure on the DNS vendors to actually implement this „because there’s RFC“.

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

On Sunday, 19 July 2020 07:52:39 UTC Ondřej Surý wrote: > I just want to point out, that I am certainly not overthinking this with my > implementors hat. The RFC and code-point puts pressure on the DNS vendors > to actually implement this „because there’s RFC“. ... i'm going to want to be able to

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

In article <32cec795-45f3-48c7-bd42-dccfe0454...@isc.org> you write: >„because there’s RFC“. The whole reason for standardization is that there’s >interoperatibility >between the implementations - and just giving the code points without >implementing this >hardly fulfills that requirement. I

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

I just want to point out, that I am certainly not overthinking this with my implementors hat. The RFC and code-point puts pressure on the DNS vendors to actually implement this „because there’s RFC“. The whole reason for standardization is that there’s interoperatibility between the

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

On Jul 7, 2020, at 4:37 AM, Töma Gavrichenkov wrote: > > Peace, > > On Tue, Jul 7, 2020, 5:17 AM Paul Hoffman wrote: > On Jul 6, 2020, at 6:07 PM, Tim Wicinski wrote: >> > To not adopt this means, the implementers could easily pick their own >> >> This seems unlikely. If they step on

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

Peace, On Tue, Jul 7, 2020, 5:17 AM Paul Hoffman wrote: > On Jul 6, 2020, at 6:07 PM, Tim Wicinski wrote: > > To not adopt this means, the implementers could easily pick their own > > This seems unlikely. If they step on unallocated code points, few > implementers will go along with that

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

On Jul 6, 2020, at 6:07 PM, Tim Wicinski wrote: > > > All > > I've been going over the CfA comments, and discussing this with my chairs and > Warren, and > perhaps the best way to walk through the logic in our decision is to work > backwards. > > > The authors are requesting a code point

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

All I've been going over the CfA comments, and discussing this with my chairs and Warren, and perhaps the best way to walk through the logic in our decision is to work backwards. The authors are requesting a code point for their algorithm in this IANA registry:

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

Paul Hoffman writes: > If the WG wants, this short draft could be a WG document. Yes please. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

Peace, On Fri, Jun 19, 2020 at 8:31 PM Eric Rescorla wrote: > My reasoning is that (as above) these algorithms are generally of > low interest and that requiring community review for code point > registration has the result of consuming quite scarce resources > in the service of making the

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

As I mentioned earlier, in response to "we need this on standards track" I have produced a very short draft that would remove that requirement: https://www.ietf.org/id/draft-hoffman-dnssec-iana-cons-00.txt It covers both DS records and NSEC3 records, which have similar issues with hash

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

> 19 июня 2020 г., в 21:17, Dick Franks написал(а): > > On Fri, 19 Jun 2020 at 18:12, Paul Hoffman > wrote: > On Jun 19, 2020, at 9:26 AM, Eric Rescorla > wrote: > > What's your reasoning for why there needs to be community review before

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

On Fri, 19 Jun 2020, Olafur Gudmundsson wrote: It might be better, and faster, for this WG to adopt a one-paragraph draft that makes the DS registry "RFC required", like the other DNSSEC-related registries. You are proposing a bureaucratic solution without thinking about the operational

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

> On Jun 18, 2020, at 11:30 AM, Paul Hoffman wrote: > > On Jun 18, 2020, at 7:59 AM, Dmitry Belyavsky wrote: >> The 2nd registry >> Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms >> (https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1 >> >>

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

On Fri, Jun 19, 2020 at 11:39 AM John Levine wrote: > In article 01gd...@mail.gmail.com> you write: > >> Yes. Leveraging the fact that the IETF community is in fact a community > >> seems worth the effort to have the references in registries be useful > to a > >> new developer a decade in the

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

In article you write: >> Yes. Leveraging the fact that the IETF community is in fact a community >> seems worth the effort to have the references in registries be useful to a >> new developer a decade in the future. > >OK. In that case you and I disagree. > >My reasoning is that (as above) these

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

On Fri, 19 Jun 2020 at 18:12, Paul Hoffman wrote: > On Jun 19, 2020, at 9:26 AM, Eric Rescorla wrote: > > What's your reasoning for why there needs to be community review before > there is a code point assigned? > > Historically, the quality of algorithm descriptions in early drafts has > been

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

On Fri, Jun 19, 2020 at 10:11 AM Paul Hoffman wrote: > On Jun 19, 2020, at 9:26 AM, Eric Rescorla wrote: > > What's your reasoning for why there needs to be community review before > there is a code point assigned? > > Historically, the quality of algorithm descriptions in early drafts has >

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

On Jun 19, 2020, at 9:26 AM, Eric Rescorla wrote: > What's your reasoning for why there needs to be community review before there > is a code point assigned? Historically, the quality of algorithm descriptions in early drafts has been variable. What the author considers sufficient and obvious,

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

On Fri, Jun 19, 2020 at 8:38 AM Paul Hoffman wrote: > On Jun 18, 2020, at 9:20 PM, Martin Thomson wrote: > > > > On Fri, Jun 19, 2020, at 01:30, Paul Hoffman wrote: > >> It might be better, and faster, for this WG to adopt a one-paragraph > >> draft that makes the DS registry "RFC required",

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

On Jun 18, 2020, at 9:20 PM, Martin Thomson wrote: > > On Fri, Jun 19, 2020, at 01:30, Paul Hoffman wrote: >> It might be better, and faster, for this WG to adopt a one-paragraph >> draft that makes the DS registry "RFC required", like the other >> DNSSEC-related registries. > > I think you

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

On 6/19/20 6:20 AM, Martin Thomson wrote: > As long as the space of codepoints isn't too small (2^16 is fine), then I see > no reason not to allow external publications request a value as long as they > don't abuse the privilege. The space for DNSKEY and DS algorithms is one octet, so each of

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

On Fri, Jun 19, 2020, at 01:30, Paul Hoffman wrote: > It might be better, and faster, for this WG to adopt a one-paragraph > draft that makes the DS registry "RFC required", like the other > DNSSEC-related registries. I think you mean "Specification Required". RFC required has the same net

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

On Thu, 18 Jun 2020, Paul Hoffman wrote: On Jun 18, 2020, at 7:59 AM, Dmitry Belyavsky wrote: The 2nd registry Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms (https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

> On 18 Jun 2020, at 16:01, Joe Abley wrote: > > On Jun 18, 2020, at 16:48, Paul Hoffman wrote: > >> Why is this WG considering making this document Standards Track instead of >> Informational? Also, why is the WG considering putting the document in our >> work stream at all? Can the WG

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

> On 18 Jun 2020, at 16:30, Paul Hoffman wrote: > > It might be better, and faster, for this WG to adopt a one-paragraph draft > that makes the DS registry "RFC required", like the other DNSSEC-related > registries. +1 signature.asc Description: Message signed with OpenPGP

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

On Jun 18, 2020, at 7:59 AM, Dmitry Belyavsky wrote: > The 2nd registry > Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms > (https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1 >

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

On Jun 18, 2020, at 16:48, Paul Hoffman wrote: > Why is this WG considering making this document Standards Track instead of > Informational? Also, why is the WG considering putting the document in our > work stream at all? Can the WG can bring much value to the document itself? > We do have

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

Hi Paul, > Why is this WG considering making this document Standards Track instead of > Informational? Also, why is the > WG considering putting the document in our work stream at all? Can the WG can > bring much value to the > document itself? We do have lots of other things we are working on.

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

Dear Paul, On Thu, Jun 18, 2020 at 5:48 PM Paul Hoffman wrote: > Why is this WG considering making this document Standards Track instead of > Informational? Also, why is the WG considering putting the document in our > work stream at all? Can the WG can bring much value to the document itself?

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

Why is this WG considering making this document Standards Track instead of Informational? Also, why is the WG considering putting the document in our work stream at all? Can the WG can bring much value to the document itself? We do have lots of other things we are working on. There is no