Subject: Re: [DNSOP] Last Call: <draft-ietf-dnsop-algorithm-update-05.txt> (Algorithm Implementation Requirements and Usage Guidance for DNSSEC) to Proposed Standard

From: Warren Kumari <[email-masked]>
Date: Mon, 4 Mar 2019 10:23:35 -0500

On Thu, Feb 28, 2019 at 10:13 AM Peter van Dijk <[email-masked]>
wrote:

> On 13 Feb 2019, at 20:29, The IESG wrote:
>
> > The IESG has received a request from the Domain Name System Operations
> > WG
> > (dnsop) to consider the following document: - 'Algorithm
> > Implementation
> > Requirements and Usage Guidance for DNSSEC'
> >   <draft-ietf-dnsop-algorithm-update-05.txt> as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> > final
> > comments on this action. Please send substantive comments to the
> > [email-masked] mailing lists by 2019-02-27. Exceptionally, comments may
> > be
> > sent to [email-masked] instead. In either case, please retain the
> > beginning of
> > the Subject line to allow automated sorting.
>
> As this pertains to a section that will apparently be removed for
> publication, only posting it here on dnsop@ for historical reasons:
>
>
So, RFC7942 (the one about "The Implementation Status" section) says that
this section should contain a note asking for it to be removed (and even
includes boilerplate to copy and paste) -- this document instead says "The
following table contains the status of support in the open-source DNS
signers and validators in the current released versions as of the time
writing this document." which implies it will be left in the document. I
personally think that this is good / helpful, but am not sure how the rest
of the IESG will feel about this...

As of 28-Feb-2019 14:02 I see pdns-4.2.0-beta1 available for download, so I
think that doing what Peter requests is fine.

So, my plan is to 1: ask the authors to please swap the Y to an N as below
and 2: progress the document with the hope that this section will survive
the publication process.

The March telechats are often really full - ADs who are leaving the IESG
try and get old / stuck work finished and off their plate - and so this
would likely only show up on the 2019-04-11 telechat -- so if anyone really
objects to this being (attempted to be) left in, please shout.

W

> PowerDNS has removed all GOST support as of version 4.2, which is due to
> be released any day now, so please change that cell in section 6.1 to N.
>
> Kind regards,
> --
> Peter van Dijk
> PowerDNS.COM BV - https://www.powerdns.com/
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: "Peter van Dijk" <[email-masked]>
Date: Mon, 04 Mar 2019 16:36:32 +0100

Hi Warren,

> of the IESG will feel about this...

I always found the removal a very unhelpful idea. A different draft 
comes to mind where the implementation section mentioned the ways in 
which almost every implementation, consistently, deviated from the 
draft, which would be very useful information to future implementors!

I indeed also noticed that this draft lacked that note, but Paul Wouters 
replied this via Twitter:

letoams: @oerdnj @Habbie ohh. well that whole section will be cut anyway 
before RFC :) If we do another rev based on IETF LC, I will update it 
<https://twitter.com/letoams/status/1101136424361955329>

> objects to this being (attempted to be) left in, please shout.

If it turns out the section is going to be removed before publication, 
then of course, don’t bother with the change. If the section will 
survive, and it is felt that this small change will hold up publication, 
then please also do not bother.

Otherwise, if it turns out we can easily get this change in, please do.

Kind regards,

---

From: Paul Wouters <[email-masked]>
Date: Mon, 4 Mar 2019 11:05:20 -0500 (EST)

On Mon, 4 Mar 2019, Warren Kumari wrote:

> So, my plan is to 1: ask the authors to please swap the Y to an N as below and 2: progress the document with the hope that this
> section will survive the publication process. 

But I do not hope that.

> The March telechats are often really full - ADs who are leaving the IESG try and get old / stuck work finished and off their
> plate - and so this would likely only show up on the 2019-04-11 telechat -- so if anyone really objects to this being (attempted
> to be) left in, please shout.

I think it should not be in the document. For one, it will be quickly
outdated information over the years as implementations release new
versions. Second, it will lead to people putting these sections in for
marketing. I think RFCs should avoid naming products whenever possible.

I'm happy to do a new rev that includes an improved "remove me" note to
IANA and the pdns update.

Paul

---

From: Warren Kumari <[email-masked]>
Date: Mon, 4 Mar 2019 11:34:03 -0500

On Mon, Mar 4, 2019 at 11:05 AM Paul Wouters <[email-masked]> wrote:

> > So, my plan is to 1: ask the authors to please swap the Y to an N as
> below and 2: progress the document with the hope that this
> try and get old / stuck work finished and off their
> > plate - and so this would likely only show up on the 2019-04-11 telechat
> -- so if anyone really objects to this being (attempted
That works for me too...
W

---

From: Michael Sinatra <[email-masked]>
Date: Mon, 4 Mar 2019 16:39:43 -0800

Section 8 - Acknowledgements:

"We wish to thank Michael Sinatra, Roland van Rijswijk-Deij, Olafur
Gudmundsson, Paul Hoffman and Evan Hunt for their imminent feedback."

Paraphrasing one of my colleagues, is the part about "imminent feedback"
a prediction, or a hint that we are supposed to give more feedback? :-)

My most imminent feedback--right now--is that I think the language in
Section 3 has come together really nicely and does a good job of
informing operators of the trade-offs of using the different algorithms,
and it provides good recommendations.  I certainly support advancing it.

michael

On 2/13/19 11:29 AM, The IESG wrote:
> 
> The IESG has received a request from the Domain Name System Operations WG
> (dnsop) to consider the following document: - 'Algorithm Implementation
> The IESG plans to make a decision in the next few weeks, and solicits final
> [email-masked] mailing lists by 2019-02-27. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the beginning of
> Abstract
>    The DNSSEC protocol makes use of various cryptographic algorithms in
>    order to provide authentication of DNS data and proof of non-
>    existence.  To ensure interoperability between DNS resolvers and DNS
>    authoritative servers, it is necessary to specify a set of algorithm
>    implementation requirements and usage guidelines to ensure that there
>    is at least one algorithm that all implementations support.  This
>    document defines the current algorithm implementation requirements
>    and usage guidance for DNSSEC.  This document obsoletes [RFC6944].
> 
> 
> 
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> 
>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 4 Mar 2019 20:06:09 -0500

Ah yes. "imminent" was a reminder of their commitment to volunteer to give
feedback :)

If we do another rev as a result of this call, I'll remove it. Otherwise,
I'll leave a note with the RFC Editor to do so.

Paul

---

From: Warren Kumari <[email-masked]>
Date: Tue, 12 Mar 2019 11:27:21 +0900

On Tue, Mar 5, 2019 at 1:34 AM Warren Kumari <[email-masked]> wrote:

>> > The March telechats are often really full - ADs who are leaving the
>> IESG try and get old / stuck work finished and off their
>> > plate - and so this would likely only show up on the 2019-04-11
>> telechat -- so if anyone really objects to this being (attempted

I was hoping to see this update before the draft cutoff; as that didn't
happen, I've decided to start the ballot, and have added a note to explain
that this is intended to be removed -- please remember to add the "Please
remove" whenever you address the IESG comments (of which I'm sure there
will be some)

W

> W
>
>
>
>> Paul
>>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.