Re: [DNSOP] IETF meeting prep and what
On 6/30/2021 6:28 PM, Mark Andrews wrote: I’d argue that there are a magnitude more resolvers Yes. Be pedantic! :-) I said "recursive resolver" and I really mean caching recursive resolver as opposed to stub resolver. Fair? I may be behind times, but few if any stub resolvers were actually doing their own DNSSEC validation (e.g. sending a CD bit to their recursive resolver and getting back all of the DNSSEC related records). than browsers in the world. There are lots of devices that have a resolver but don’t have a browser. Think of all the smart light bulbs. They all need to be able to update their trust anchors. DNSSEC deployment is still in its infancy. I get what you mean, but I don't actually think many of the tiniest of IOT devices will have anything more than an unsecure way of looking up their back office system - and then using TLS or something else to verify the connection. Their only CA trust anchor will be to their vendor to start with and then to whatever local manager takes over ownership. I could be wrong, but DNS has its greatest strength where you get passed a lot of different names that need to be looked up, and that mostly doesn't describe the IOT side of things. Later, Mike On 1 Jul 2021, at 05:26, Michael StJohns wrote: Peter et al - It might be useful to review RFC 4986 - https://www.rfc-editor.org/rfc/rfc4986.html - Requirements Related to DNS Security Trust Anchor Rollover - to understand what the problem requirements were/are before resurrecting this discussion again. If the requirements have changed, then perhaps we need a new solution, but we should probably update 4986 before tossing 5011. Peter - WRT to your analogy to the CA system, I will note that browser clients (where the trust anchors are embedded for the CA) are not even close to being updated in the same manner as recursive resolvers (not simply "DNS clients") and many resolvers are used to provide services within various small and large organizations rather than being owned and updated by a single person. For one thing, there are orders of magnitude more browers than there are resolvers. For another, resolvers are rarely updated automatically. What would be interesting is to get some idea of the set of resolvers with no active management being performed on them - including software updates. Mike On 6/30/2021 2:59 PM, Peter van Dijk wrote: Hello DNSOP, I propose replacing rfc5011-security-considerations with a short document deprecating 5011 in its entirety. I am happy to write text for that, if there is an appetite - when the WG queue is small enough! I see this ruffled some feathers. Here's a more nuanced version. I feel that 5011, for the purpose of root key rollovers, is the wrong tool, -especially- combined with the trust anchor signaling that various resolver stacks sent to the root. Lack of clarity about where various signals came from, combined with some interesting bugs in implementations, has led to a lot of wild goose chases, and it would not surprise me (but I cannot prove) that bad data is what delayed the first roll for so long. Not actual problems predicted by the data; just bad data. (I have mentioned before that I think the trust anchor signalling was a mistake too, and any calls for 'more of this' are 'calls for more bad data' and we do not need more bad data.) I feel that the right mechanism for root key distribution is software distributors. This is working fine for the CA system, and with keys announced far enough in advance, should work fine for DNSSEC. Software distributors have solved this problem; they are very good at distributing things; I suggest we let them solve this for us. rfc5011-security-considerations is a good document, and I apologise for targeting it unfairly - my problem with 5011 is as above. Given my next two point, it probably makes sense to publish rfc5011-security-considerations. With heaps of 5011 'client' implementations out there, I am in no way proposing that root rolls happen in a way that that software could not follow along. I am only proposing that we write down that 5011 is not the best fit for the problem, and recommend against more client implementations of it *for the purpose of root key rolls*. I think (can't find it right now) that somebody mentioned that 5011 has its place outside of the root key system, inside enterprises. I'm inclined to disagree, but do not feel entirely capable of judging that. If (again, when there's WG bandwidth) we draft a document about why 5011 is a bad fit for the root, perhaps somebody can contribute text about the level-of-fit for other use cases. Kind regards, ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IETF meeting prep and what
I’d argue that there are a magnitude more resolvers than browsers in the world. There are lots of devices that have a resolver but don’t have a browser. Think of all the smart light bulbs. They all need to be able to update their trust anchors. DNSSEC deployment is still in its infancy. > On 1 Jul 2021, at 05:26, Michael StJohns wrote: > > Peter et al - > > It might be useful to review RFC 4986 - > https://www.rfc-editor.org/rfc/rfc4986.html - Requirements Related to DNS > Security Trust Anchor Rollover - to understand what the problem requirements > were/are before resurrecting this discussion again. If the requirements > have changed, then perhaps we need a new solution, but we should probably > update 4986 before tossing 5011. > > Peter - > > WRT to your analogy to the CA system, I will note that browser clients (where > the trust anchors are embedded for the CA) are not even close to being > updated in the same manner as recursive resolvers (not simply "DNS clients") > and many resolvers are used to provide services within various small and > large organizations rather than being owned and updated by a single person. > For one thing, there are orders of magnitude more browers than there are > resolvers. For another, resolvers are rarely updated automatically. What > would be interesting is to get some idea of the set of resolvers with no > active management being performed on them - including software updates. > > Mike > > > > On 6/30/2021 2:59 PM, Peter van Dijk wrote: >> Hello DNSOP, >> >>> I propose replacing rfc5011-security-considerations with a short document >>> deprecating 5011 in its entirety. I am happy to write text for that, if >>> there is an appetite - when the WG queue is small enough! >> I see this ruffled some feathers. Here's a more nuanced version. >> >> I feel that 5011, for the purpose of root key rollovers, is the wrong tool, >> -especially- combined with the trust anchor signaling that various resolver >> stacks sent to the root. Lack of clarity about where various signals came >> from, combined with some interesting bugs in implementations, has led to a >> lot of wild goose chases, and it would not surprise me (but I cannot prove) >> that bad data is what delayed the first roll for so long. Not actual >> problems predicted by the data; just bad data. (I have mentioned before that >> I think the trust anchor signalling was a mistake too, and any calls for >> 'more of this' are 'calls for more bad data' and we do not need more bad >> data.) >> >> I feel that the right mechanism for root key distribution is software >> distributors. This is working fine for the CA system, and with keys >> announced far enough in advance, should work fine for DNSSEC. Software >> distributors have solved this problem; they are very good at distributing >> things; I suggest we let them solve this for us. >> >> rfc5011-security-considerations is a good document, and I apologise for >> targeting it unfairly - my problem with 5011 is as above. Given my next two >> point, it probably makes sense to publish rfc5011-security-considerations. >> >> With heaps of 5011 'client' implementations out there, I am in no way >> proposing that root rolls happen in a way that that software could not >> follow along. I am only proposing that we write down that 5011 is not the >> best fit for the problem, and recommend against more client implementations >> of it *for the purpose of root key rolls*. >> >> I think (can't find it right now) that somebody mentioned that 5011 has its >> place outside of the root key system, inside enterprises. I'm inclined to >> disagree, but do not feel entirely capable of judging that. If (again, when >> there's WG bandwidth) we draft a document about why 5011 is a bad fit for >> the root, perhaps somebody can contribute text about the level-of-fit for >> other use cases. >> >> Kind regards, > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IETF meeting prep and what
Peter et al - It might be useful to review RFC 4986 - https://www.rfc-editor.org/rfc/rfc4986.html - Requirements Related to DNS Security Trust Anchor Rollover - to understand what the problem requirements were/are before resurrecting this discussion again. If the requirements have changed, then perhaps we need a new solution, but we should probably update 4986 before tossing 5011. Peter - WRT to your analogy to the CA system, I will note that browser clients (where the trust anchors are embedded for the CA) are not even close to being updated in the same manner as recursive resolvers (not simply "DNS clients") and many resolvers are used to provide services within various small and large organizations rather than being owned and updated by a single person. For one thing, there are orders of magnitude more browers than there are resolvers. For another, resolvers are rarely updated automatically. What would be interesting is to get some idea of the set of resolvers with no active management being performed on them - including software updates. Mike On 6/30/2021 2:59 PM, Peter van Dijk wrote: Hello DNSOP, I propose replacing rfc5011-security-considerations with a short document deprecating 5011 in its entirety. I am happy to write text for that, if there is an appetite - when the WG queue is small enough! I see this ruffled some feathers. Here's a more nuanced version. I feel that 5011, for the purpose of root key rollovers, is the wrong tool, -especially- combined with the trust anchor signaling that various resolver stacks sent to the root. Lack of clarity about where various signals came from, combined with some interesting bugs in implementations, has led to a lot of wild goose chases, and it would not surprise me (but I cannot prove) that bad data is what delayed the first roll for so long. Not actual problems predicted by the data; just bad data. (I have mentioned before that I think the trust anchor signalling was a mistake too, and any calls for 'more of this' are 'calls for more bad data' and we do not need more bad data.) I feel that the right mechanism for root key distribution is software distributors. This is working fine for the CA system, and with keys announced far enough in advance, should work fine for DNSSEC. Software distributors have solved this problem; they are very good at distributing things; I suggest we let them solve this for us. rfc5011-security-considerations is a good document, and I apologise for targeting it unfairly - my problem with 5011 is as above. Given my next two point, it probably makes sense to publish rfc5011-security-considerations. With heaps of 5011 'client' implementations out there, I am in no way proposing that root rolls happen in a way that that software could not follow along. I am only proposing that we write down that 5011 is not the best fit for the problem, and recommend against more client implementations of it *for the purpose of root key rolls*. I think (can't find it right now) that somebody mentioned that 5011 has its place outside of the root key system, inside enterprises. I'm inclined to disagree, but do not feel entirely capable of judging that. If (again, when there's WG bandwidth) we draft a document about why 5011 is a bad fit for the root, perhaps somebody can contribute text about the level-of-fit for other use cases. Kind regards, ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IETF meeting prep and what
On 30 Jun 2021, at 14:59, Peter van Dijk wrote: > I feel that the right mechanism for root key distribution is software > distributors. This is working fine for the CA system, and with keys announced > far enough in advance, should work fine for DNSSEC. Software distributors > have solved this problem; they are very good at distributing things; I > suggest we let them solve this for us. We actually spent some time back in 2009/2010 packaging trust anchors in a way that could take advantage of existing (e.g. code-signing) PKIs, specifically to facilitate distribution to software vendors. I haven't checked very recently, but I don't think there was any sign that the mechanism was being used by anybody in the decade or so that followed. See RFC 7958 section 2.3. I mention this simply because it was our best guess at the time at how to distribute trust anchors securely (with a respectable chain of custody) from the KMF in which the keys were generated right through to the code publication pipeline operated by software vendors. Quite possibly it was a bad guess. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IETF meeting prep and what
Hello DNSOP, > I propose replacing rfc5011-security-considerations with a short document > deprecating 5011 in its entirety. I am happy to write text for that, if there > is an appetite - when the WG queue is small enough! I see this ruffled some feathers. Here's a more nuanced version. I feel that 5011, for the purpose of root key rollovers, is the wrong tool, -especially- combined with the trust anchor signaling that various resolver stacks sent to the root. Lack of clarity about where various signals came from, combined with some interesting bugs in implementations, has led to a lot of wild goose chases, and it would not surprise me (but I cannot prove) that bad data is what delayed the first roll for so long. Not actual problems predicted by the data; just bad data. (I have mentioned before that I think the trust anchor signalling was a mistake too, and any calls for 'more of this' are 'calls for more bad data' and we do not need more bad data.) I feel that the right mechanism for root key distribution is software distributors. This is working fine for the CA system, and with keys announced far enough in advance, should work fine for DNSSEC. Software distributors have solved this problem; they are very good at distributing things; I suggest we let them solve this for us. rfc5011-security-considerations is a good document, and I apologise for targeting it unfairly - my problem with 5011 is as above. Given my next two point, it probably makes sense to publish rfc5011-security-considerations. With heaps of 5011 'client' implementations out there, I am in no way proposing that root rolls happen in a way that that software could not follow along. I am only proposing that we write down that 5011 is not the best fit for the problem, and recommend against more client implementations of it *for the purpose of root key rolls*. I think (can't find it right now) that somebody mentioned that 5011 has its place outside of the root key system, inside enterprises. I'm inclined to disagree, but do not feel entirely capable of judging that. If (again, when there's WG bandwidth) we draft a document about why 5011 is a bad fit for the root, perhaps somebody can contribute text about the level-of-fit for other use cases. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IETF meeting prep and what
On Fri, Jun 18, 2021 at 12:06 PM Joe Abley wrote: > On 18 Jun 2021, at 14:45, Paul Wouters wrote: > > > On Jun 18, 2021, at 13:41, Peter van Dijk > wrote: > > > >> I propose replacing rfc5011-security-considerations with a short > document deprecating 5011 in its entirety. > > > > Eh? 5011 is baked into various software. Why would replace 5011 ? > > > > Did I miss something? > > There were some conversations adjacent to the last great root zone KSK > roll excitement about how a more measurable and reliable mechanism might be > useful. My memory is that there might be value in specifying a new > mechanism that could be used as an alternative to or in conjunction with > 5011, though, not that 5011 was fundamentally unsound and deserved to be > deprecated. > > I agree that, in the end, 5011 seems to have done a reasonable job -- it > was just hard to predict with any degree of comfort or certainty. > I didn't realize the -security-considerations document had the history in the wg during wglc (I missed that entirely, sorry). And hadn't really closely read either the draft (even in its latest iteration), or looked at 5011 itself with a critical eye. I am in favor of all of the following: - Advancing the -security-considerations draft as Informational (e.g. as IETF LC) - Keeping 5011 or a successor - Working on an informal 5011 thing to document: - What it can and cannot do - Requirements on how to strengthen it against the replay attack causing failed rollover - Requirements for how to strengthen it against a compromised key (discovered empirically for example) - Requirements for how to protect against change-of-control via single compromised key - Working on a formal 5011-bis informed by both the present -security-considerations work, and the informal thing (previous bullet) I am willing to work on the last two items as a co-author, but probably don't have the cycles to be the holder-of-the-pen. I have specific ideas, so this isn't just wishful thinking, I don't think. However, whether the -bis is able to get consensus is not a foregone conclusion, I don't think. Having a stronger and more resilient 5011 is something I think that may be important, particularly for use in environments which are not the Root Trust Anchor (e.g. private trust anchors in various environments, including the 2-letter undelegated use case, the internal-only subdomain use case, and possibly some of the HomeNet use cases presumably.). Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IETF meeting prep and what
On 23 Jun 2021, at 12:28, Vladimír Čunát wrote: > On 18/06/2021 19.40, Peter van Dijk wrote: > >> I propose replacing rfc5011-security-considerations with a short document >> deprecating 5011 in its entirety. I am happy to write text for that, if >> there is an appetite - when the WG queue is small enough! > > I agree that 5011 doesn't seem really useful (anymore). > > We have it in Knot Resolver but recommend not to use it, because it's just > more trouble than worth in practice. Notably, (all) resolver software needs > much more frequent updates than the rate of root KSK rollovers, so it's > easier to distribute root DS within the updates; some Linux distros even > package these separately and share them among different resolver packages. > Even if you're conservative and use BIND ESV or similar, I believe it's a > better approach than 5011. For non-root keys there doesn't seem much point > nowadays, as getting a chain from root is better. > > (By the way, an "interesting" example: router with DNSSEC validation and > factory reset / rollback, commonly shelved for a year, unreliable clock, etc.) There are a variety of mechanisms available to identify and configure a trust anchor to use in a validator, some automatic and some manual; some rely upon having an existing, functional trust anchor to introduce a new one, some use other trusted paths such as vendor update processes and the web PKI. There are almost certainly mechanisms we don't know about, as well as the variety with which we are familiar. There are also a variety of scenarios in which trust anchor maintenance is important. Some scenarios involve informed administrators; some involve uninformed users; some involve isolated devices that have no immediate human administrator or user. Some (as you point out) feature long air-gapped periods between configuration and use. We do not have a complete understanding of the breadth of the set of scenarios. Given that there is such a variety of existing mechanisms and possible use-cases, and considering the profound lack of measurement which could inform us about which mechanisms are being used (or work) and which are not (or don't), I think it's premature to start talking about retiring particular mechanisms either as operational practice or in the sense of deprecation. As one of the people who spent painful amounts of time trying to contact people by phone and e-mail to find out whether the dirty signals we were worried about during the last (and only!) root zone KSK roll, I can attest that RFC 5011 certainly works well for some people. I think it's fair to say we don't have a good way of quantifying that data point into a more general statement that is stronger than anecdotal. This is not a firm foundation on which to build a plan. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IETF meeting prep and what
On 18/06/2021 19.40, Peter van Dijk wrote: aname can go; I trust the WG feels SVCB will supersede it. Yes, please. I propose replacing rfc5011-security-considerations with a short document deprecating 5011 in its entirety. I am happy to write text for that, if there is an appetite - when the WG queue is small enough! I agree that 5011 doesn't seem really useful (anymore). We have it in Knot Resolver but recommend not to use it, because it's just more trouble than worth in practice. Notably, (all) resolver software needs much more frequent updates than the rate of root KSK rollovers, so it's easier to distribute root DS within the updates; some Linux distros even package these separately and share them among different resolver packages. Even if you're conservative and use BIND ESV or similar, I believe it's a better approach than 5011. For non-root keys there doesn't seem much point nowadays, as getting a chain from root is better. (By the way, an "interesting" example: router with DNSSEC validation and factory reset / rollback, commonly shelved for a year, unreliable clock, etc.) --Vladimir ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IETF meeting prep and what
On Fri, Jun 18, 2021 at 7:41 PM Peter van Dijk wrote: > > On Wed, 2021-06-16 at 19:38 -0400, Tim Wicinski wrote: > > All > > > > The chairs have been doing prep work for the upcoming IETF meeting; one > > issue that we are working on is reaching out to authors whose working group > > documents have recently expired. While doing this, Benno did some > > datatracker stuff and ended up with this list > > > > https://datatracker.ietf.org/doc/search?name=draft-ietf-dnsop==on=group=DNSOP > > > > All documents from 1 January 2016 onward are open for discussion. For the > > older documents that are left - if someone wishes to take them on, please > > reach out. > > aname can go; I trust the WG feels SVCB will supersede it. I concur. -Anthony -- DNSimple.com http://dnsimple.com/ Twitter: @dnsimple ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IETF meeting prep and what
Peter van Dijk writes: > I propose replacing rfc5011-security-considerations I keep meaning to republish it with Olafur's suggested reduced title (since it's really describing just one problem). But it's unlikely to get published as an RFC due to lack of consensus after a long drawn out conversation where most of the WG stopped reading due to the harsh language of some messages. It can probably be dropped from the active list because of this. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IETF meeting prep and what
On Jun 18, 2021, at 16:36, Paul Wouters wrote: > Sure, but if we were to deprecate 5011, what would we expect to happen > when we want to do another rollover ? To be more clear, I was *not* suggesting that 5011 should be deprecated. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IETF meeting prep and what
On Fri, 18 Jun 2021, Joe Abley wrote: On Jun 18, 2021, at 13:41, Peter van Dijk wrote: I propose replacing rfc5011-security-considerations with a short document deprecating 5011 in its entirety. Eh? 5011 is baked into various software. Why would replace 5011 ? Did I miss something? There were some conversations adjacent to the last great root zone KSK roll excitement about how a more measurable and reliable mechanism might be useful. My memory is that there might be value in specifying a new mechanism that could be used as an alternative to or in conjunction with 5011, though, not that 5011 was fundamentally unsound and deserved to be deprecated. I agree that, in the end, 5011 seems to have done a reasonable job -- it was just hard to predict with any degree of comfort or certainty. Sure, but if we were to deprecate 5011, what would we expect to happen when we want to do another rollover ? We would still have software out there doing 5011, so we can't do it dramatically different. Which would lead me to think at best we could do a 5011bis that's mostly compatible but somehow improved on what we missed, the reporting. But that is quite different from "deprecating 5011 in its entirety". Paul "no-not-a-dns-flagday" Wouters ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IETF meeting prep and what
On 18 Jun 2021, at 14:45, Paul Wouters wrote: > On Jun 18, 2021, at 13:41, Peter van Dijk wrote: > >> I propose replacing rfc5011-security-considerations with a short document >> deprecating 5011 in its entirety. > > Eh? 5011 is baked into various software. Why would replace 5011 ? > > Did I miss something? There were some conversations adjacent to the last great root zone KSK roll excitement about how a more measurable and reliable mechanism might be useful. My memory is that there might be value in specifying a new mechanism that could be used as an alternative to or in conjunction with 5011, though, not that 5011 was fundamentally unsound and deserved to be deprecated. I agree that, in the end, 5011 seems to have done a reasonable job -- it was just hard to predict with any degree of comfort or certainty. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IETF meeting prep and what
On Jun 18, 2021, at 13:41, Peter van Dijk wrote: > > I propose replacing rfc5011-security-considerations with a short document > deprecating 5011 in its entirety. Eh? 5011 is baked into various software. Why would replace 5011 ? Did I miss something? Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IETF meeting prep and what
On Wed, 2021-06-16 at 19:38 -0400, Tim Wicinski wrote: > All > > The chairs have been doing prep work for the upcoming IETF meeting; one issue > that we are working on is reaching out to authors whose working group > documents have recently expired. While doing this, Benno did some datatracker > stuff and ended up with this list > > https://datatracker.ietf.org/doc/search?name=draft-ietf-dnsop==on=group=DNSOP > > All documents from 1 January 2016 onward are open for discussion. For the > older documents that are left - if someone wishes to take them on, please > reach out. aname can go; I trust the WG feels SVCB will supersede it. I hope MarkA can revive glue-is-not-optional. I propose replacing rfc5011-security-considerations with a short document deprecating 5011 in its entirety. I am happy to write text for that, if there is an appetite - when the WG queue is small enough! There are quite some things I like in rfc2317-bis, especially the parts where it proposes something -other than- slashes in labels. I am not offering to take it on at this time, though. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IETF meeting prep and what
On Wed, Jun 16, 2021 at 7:39 PM Tim Wicinski wrote: > All > > The chairs have been doing prep work for the upcoming IETF meeting; one > issue that we are working on is reaching out to authors whose working group > documents have recently expired. While doing this, Benno did some > datatracker stuff and ended up with this list > > > https://datatracker.ietf.org/doc/search?name=draft-ietf-dnsop==on=group=DNSOP > > Which goes back to 1999 and has lots of old cruft. > > We chatted with our IESG Overlord Warren, and we're looking at gracefully > removing drafts we’re unlikely to work on or advance from the datatracker’s > view of the WG. The intent is that they won’t clutter a list that’s > supposed to help WG chairs and contributors track what we’re actively > working on. > > Our plan is to release from the WG all drafts that were last updated prior > to 1 January 2016. This action may create some emails to the mailing list > or the authors, and we want to make you aware of this before we start. > > All documents from 1 January 2016 onward are open for discussion. For > the older documents that are left - if someone wishes to take them on, > please reach out. > Thank you very much, chairs! While having a discussion with the IESG, I had a look at the number of Active Drafts that we have, and compared it to other workinggroups -- DNSOP currently has 14 listed, with 3 in some form of publication requested (draft-ietf-dnsop-iana-class-type-yang, draft-ietf-dnsop-nsec-ttl, draft-ietf-dnsop-rfc7816bis), leaving 11 "active" ones. Only 6 WGs have more than this, and some of these are in states like "Implementation needed", etc. I think it would be good if we could try and clear some of the active queue (and any expired WG documents that we still want to work on) before adopting many new documents. This isn't "no new work!", but rather "let's try to prioritize existing work first". The intent here is to allow us to focus more on each individual document, and not have our attention scattered between so many. W Poorly organized data here: https://docs.google.com/spreadsheets/d/1AbOEkwVEIhIEPJ1TLUB92D-va7zszRlozZDkDBcYPw8/edit?usp=sharing > > > Thanks > > Benno/Suzanne/Tim > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- The computing scientist’s main challenge is not to get confused by the complexities of his own making. -- E. W. Dijkstra ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
