Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing
I can't speak for all of .gov, but I think the draft is ready for publication. Once it has an RFC number it will get worked into products and ops manuals. Since a lot of .gov agencies outsource, or use appliances, I wouldn't expect much feedback. :) Scott From: DNSOP dnsop-boun...@ietf.org on behalf of Paul Ebersman list-dn...@dragon.net Sent: Saturday, July 19, 2014 5:21 PM To: dnsop@ietf.org Subject: Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing ajs giving useful advice, even if not perfect, on this topic will be ajs more helpful than producting perfect advice. [...] ajs Please publish it. +1 Many folks won't implement this until it's an RFC (.gov, etc.) but will and give feedback once it's out. Perfect is the enemy of progress... ___ 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] draft-ietf-dnsop-dnssec-key-timing
srose I can't speak for all of .gov, but I think the draft is ready for srose publication. Once it has an RFC number it will get worked into srose products and ops manuals. Since a lot of .gov agencies srose outsource, or use appliances, I wouldn't expect much feedback. :) Having worked recently at one of said vendors, where .gov customers wanted that DNSSEC checkbox thingie but did use various NIST and other standards, it means that this RFC will get into the check list of RFCs vendors need to say yes to in bids, so there will be use of the recommendations. Sadly, you are probably right on feedback from some of the vendors and most .govs... ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing
On Mon, Jul 21, 2014 at 03:10:16PM -0400, Paul Ebersman wrote: Sadly, you are probably right on feedback from some of the vendors and most .govs... Not everyone who consumes our documents (or the results of them) is going to tell us about their experiences. On the other hand, a couple of blog posts that read, Well, I tried to follow RFC but after I read it I was actually more confused than when I started, or, If you read RFC, it says quite clearly that foo, will tell us whether we've a big problem or a little one or no problem at all. Right now, _nobody_ who doesn't already know what a DNSOP is will know about this draft. At least if we publish it, there's some hope people will find it when searching for relevant RFCs. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing
Not everyone who consumes our documents (or the results of them) is going to tell us about their experiences. I'm adding DNSSEC to the zones I host, and I've already found it useful. Ship it, please. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing
ajs giving useful advice, even if not perfect, on this topic will be ajs more helpful than producting perfect advice. [...] ajs Please publish it. +1 Many folks won't implement this until it's an RFC (.gov, etc.) but will and give feedback once it's out. Perfect is the enemy of progress... ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing
On Aug 20, 2012, at 17:33 , Paul Hoffman wrote: On Aug 20, 2012, at 6:19 AM, Peter Koch p...@denic.de wrote: Andrew, In the archives since the meeting, I observe some comments at http://www.ietf.org/mail-archive/web/dnsop/current/msg09783.html. But I do not observe the announcement of a WGLC. I am wondering when we might expect that call. both chairs have taken advantage of the season at least a bit. One of the chairs has recused himself being a co-editor, so this is the document shepherd. Issuing the WGLC involves reviewing the draft as well as the recent discussion to generate framing questions. In this particular case, several members of the WG, some of which I remember having been in favour of WGLC during the Vancouver meeting, had expressed support for a major change to the draft suggested by Matthijs Mekking on July 24 http://www.ietf.org/mail-archive/web/dnsop/current/msg09767.html That would basically mean folding significant parts of 'keytiming bis' into the current 'key timing' draft. That was my (probably biased) memory as well. My current reading of the sense of the WG is that we move to WGLC with -03, declaring the July 24 suggestion out of scope for this document and keep momentum for 'dnssec bis'. That's one way to do it. A better one would be to start WG LC on key-timing with an explicit question to the WG about folding in the keytiming-bis changes. That way, the WG would know the status of both, and we would would possibly produce just one document. The operations community would be better off with just one document, if this WG can do that. Not to question the abilities of the WG, but I still have to ask whether (in your opinion) the operations community would be better off with a single document that may be finished around Christmas Eve 2020 or rather live with multiple docs that are published somewhat sooner than that. Having more than one requires them to know the RFC numbers for all the documents for which they are possibly interested. Other WGs have problems with developers having to know about three RFCs for a protocol; it seems odd to think that us having a dozen documents for operators is a good idea. Long documents are not a problem if they are reasonably well organized with truly parallel sections. So, on principle I have to disagree with this. Multiple documents are a method of abstraction and organization, just like directories, or, for that matter, dividing your source into multiple files. If it is really a problem to have to refer to more than on RFC, then I think we made a huge error many years ago when we gave RFCs a number. We should have gone for The RFC For The Internet (yet to be published) and meanwhile kept the Internet running on various versions of expired drafts. Tongue-in-cheek and no offence intended ;-) Regards, Johan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing
On 2012-08-30 9:40 AM, Johan Ihrén wrote: On Aug 20, 2012, at 17:33 , Paul Hoffman wrote: On Aug 20, 2012, at 6:19 AM, Peter Koch p...@denic.de wrote: My current reading of the sense of the WG is that we move to WGLC with -03, declaring the July 24 suggestion out of scope for this document and keep momentum for 'dnssec bis'. dnssec-bis was delegated signer. dnssec-ter was type code roll. we're on dnssec-nextgen now. That's one way to do it. A better one would be to start WG LC on key-timing with an explicit question to the WG about folding in the keytiming-bis changes. That way, the WG would know the status of both, and we would would possibly produce just one document. The operations community would be better off with just one document, if this WG can do that. Not to question the abilities of the WG, but I still have to ask whether (in your opinion) the operations community would be better off with a single document that may be finished around Christmas Eve 2020 or rather live with multiple docs that are published somewhat sooner than that. while i agree with these sentiments i have a broader concern. ietf's mantra is good engineering. if we know now that keytiming has flaws, and we are only considering publishing it because we know our own record shows that reaching consensus for keytiming-bis will take a long time, then it's an implicit indictment (by us) of our own record and habits. we should have a better reason for publishing two documents, like new ideas occurred to us after the first one was beyond reach of our pen, or they have different topics. paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing
On Aug 30, 2012, at 9:45 AM, Paul Vixie p...@redbarn.org wrote: On 2012-08-30 9:40 AM, Johan Ihrén wrote: Not to question the abilities of the WG, but I still have to ask whether (in your opinion) the operations community would be better off with a single document that may be finished around Christmas Eve 2020 or rather live with multiple docs that are published somewhat sooner than that. while i agree with these sentiments i have a broader concern. ietf's mantra is good engineering. if we know now that keytiming has flaws, and we are only considering publishing it because we know our own record shows that reaching consensus for keytiming-bis will take a long time, then it's an implicit indictment (by us) of our own record and habits. we should have a better reason for publishing two documents, like new ideas occurred to us after the first one was beyond reach of our pen, or they have different topics. A big +1. An operator who wants to know how to do rollovers will not know *or care* why they followed IETF guidance that was overturned or even clarified soon after. The reasons that the base document got delayed so horribly do not matter any more: what matters is what the WG and its leadership are willing to do today to help operators in the near future. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing
On 2012-08-30, at 13:11, Paul Hoffman paul.hoff...@vpnc.org wrote: On Aug 30, 2012, at 9:45 AM, Paul Vixie p...@redbarn.org wrote: On 2012-08-30 9:40 AM, Johan Ihrén wrote: Not to question the abilities of the WG, but I still have to ask whether (in your opinion) the operations community would be better off with a single document that may be finished around Christmas Eve 2020 or rather live with multiple docs that are published somewhat sooner than that. while i agree with these sentiments i have a broader concern. ietf's mantra is good engineering. if we know now that keytiming has flaws, and we are only considering publishing it because we know our own record shows that reaching consensus for keytiming-bis will take a long time, then it's an implicit indictment (by us) of our own record and habits. we should have a better reason for publishing two documents, like new ideas occurred to us after the first one was beyond reach of our pen, or they have different topics. A big +1. An operator who wants to know how to do rollovers will not know *or care* why they followed IETF guidance that was overturned or even clarified soon after. I suspect an increasing proportion of operators doing DNSSEC do not care how to do rollovers, in fact. They care that the software they're using to manage keys and sign things is doing the right thing. The pragmatic long-term view is, I think, that this document doesn't give advice to operators so much as advice for those implementing DNSSEC signers. I am not suggesting that operators don't care what happens under the hood, or that vendors don't care about operators. But I think the inference that this is advice to heed before you dive in and perform rollovers by hand is short-sighted. The focus ought to be advice that can be converted easily into good code. I am not a developer of DNS software, and hence don't feel well-placed to review the draft from that perspective. However, my feeling (based on words absorbed inadvertently from people who are developers) is that the document would better serve that perspective if it presented robust state machines and algorithms for arbitrary rollovers. As an operator I would very much like trustworthy tools that could take my desire (say) to roll a KSK from an N-bit alg-A key to an M-bit alg-B key and show me the timing constraints for that rollover to be completed, so I can plan the exercise, accommodate any expected delay in DS publication in parent zones, keep my relying parties informed, and hopefully have robots execute the actual zone changes for me. Working all that out by hand (and making the zone changes manually) based on the advice in dnssec-key-timing is error-prone. Joe smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing
On Aug 30, 2012, at 10:57 AM, Joe Abley joe.ab...@icann.org wrote: I suspect an increasing proportion of operators doing DNSSEC do not care how to do rollovers, in fact. They care that the software they're using to manage keys and sign things is doing the right thing. Good point, yes. The pragmatic long-term view is, I think, that this document doesn't give advice to operators so much as advice for those implementing DNSSEC signers. Yes and no. Many of the aforementioned operators are probably going to be asked are you sure that the software you are using follows the specifications and those operators are going to look for the vendor's checkmark next to the right RFC number. If so, this argues strongly for fewer RFCs for the checkmarks to match to. I am not suggesting that operators don't care what happens under the hood, or that vendors don't care about operators. But I think the inference that this is advice to heed before you dive in and perform rollovers by hand is short-sighted. The focus ought to be advice that can be converted easily into good code. Yes. Here, good should also mean code whose logs can be followed by someone who hasn't read the RFC, if needed. I am not a developer of DNS software, and hence don't feel well-placed to review the draft from that perspective. However, my feeling (based on words absorbed inadvertently from people who are developers) is that the document would better serve that perspective if it presented robust state machines and algorithms for arbitrary rollovers. As an operator I would very much like trustworthy tools that could take my desire (say) to roll a KSK from an N-bit alg-A key to an M-bit alg-B key and show me the timing constraints for that rollover to be completed, so I can plan the exercise, accommodate any expected delay in DS publication in parent zones, keep my relying parties informed, and hopefully have robots execute the actual zone changes for me. Working all that out by hand (and making the zone changes manually) based on the advice in dnssec-key-timing is error-prone. Yes. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing
Paul Vixie p...@redbarn.org wrote: while i agree with these sentiments i have a broader concern. ietf's mantra is good engineering. if we know now that keytiming has flaws, and we are only considering publishing it because we know our own record shows that reaching consensus for keytiming-bis will take a long time, then it's an implicit indictment (by us) of our own record and habits. But I thought the flaws discussed in this thread were in terms of presentation rather than engineering. (I haven't reviewed the document yet.) As far as I can tell DNSSEC implementations and deployment are still in a somewhat exploratory phase wrt key management, so it is reasonable to expect it to take a long time to work out how to simplify the document in a sensible way. I expect it to go along with good implementations of canned rollover procedures. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/20/2012 05:33 PM, Paul Hoffman wrote: On Aug 20, 2012, at 6:19 AM, Peter Koch p...@denic.de wrote: Andrew, In the archives since the meeting, I observe some comments at http://www.ietf.org/mail-archive/web/dnsop/current/msg09783.html. But I do not observe the announcement of a WGLC. I am wondering when we might expect that call. both chairs have taken advantage of the season at least a bit. One of the chairs has recused himself being a co-editor, so this is the document shepherd. Issuing the WGLC involves reviewing the draft as well as the recent discussion to generate framing questions. In this particular case, several members of the WG, some of which I remember having been in favour of WGLC during the Vancouver meeting, had expressed support for a major change to the draft suggested by Matthijs Mekking on July 24 http://www.ietf.org/mail-archive/web/dnsop/current/msg09767.html That would basically mean folding significant parts of 'keytiming bis' into the current 'key timing' draft. That was my (probably biased) memory as well. Yes, me too. My current reading of the sense of the WG is that we move to WGLC with -03, declaring the July 24 suggestion out of scope for this document and keep momentum for 'dnssec bis'. That's one way to do it. A better one would be to start WG LC on key-timing with an explicit question to the WG about folding in the keytiming-bis changes. That way, the WG would know the status of both, and we would would possibly produce just one document. The operations community would be better off with just one document, if this WG can do that. I am afraid that one document just isn't sufficient. Adding a rollover time line requires a fair amount of pages to cover the timing details (at least with the current approach). The current document now covers six time lines. When we want to add time lines for Single Type Signing Scheme, Algorithm Rollover and Policy Rollover, we can come up with about ten more time lines. It would become a very lengthy document, arguably even longer than 4641bis ;). In my opinion, it would be better to categorize them and deal with them over multiple documents (one document per category). We then could use one document which has the base terminology, so we can refer to, for example, the key state definitions in future documents. However, then we have to make sure that the key state definitions are flexible enough to be able to describe these other rollovers (and I am afraid that the current key state definitions are not). Best regards, Matthijs --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQMzT4AAoJEA8yVCPsQCW5RrcH/jYzbcEkaSCJdBUCJ4Ju9C6u P7EBEKxiL6mSPXcXPX6i9dZ8ZEnOJF3HX+1CYizLAtKHWiiUTiTduegnbCLwkn3s HvqzEE6h4izwvRZtbKRqTT05DAZGoL61/M/lhVA74z6OiP99D1BX6I9qFjxZCYeY mtOVGuaOtOcofcEf/loKCgDfy9hOzJ2HVZeptmWiTYLp/fBhYrzE3YHBePJqbQHM tTAKbgQc2whhKtCnxsKeo80Rland/F1XGb44sApijnZFsFIAEvorfdmQCQ6qsCRS PzIwTuUdYNFTiy7Bj8tT2NMAr9wfYHKvjQ6aZKKW9cTBw4ICTdedP91MPLK1Fw4= =MDnw -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing
On Aug 21, 2012, at 12:12 AM, Matthijs Mekking matth...@nlnetlabs.nl wrote: I am afraid that one document just isn't sufficient. Adding a rollover time line requires a fair amount of pages to cover the timing details (at least with the current approach). The current document now covers six time lines. When we want to add time lines for Single Type Signing Scheme, Algorithm Rollover and Policy Rollover, we can come up with about ten more time lines. It would become a very lengthy document, arguably even longer than 4641bis ;). In my opinion, it would be better to categorize them and deal with them over multiple documents (one document per category). We then could use one document which has the base terminology, so we can refer to, for example, the key state definitions in future documents. However, then we have to make sure that the key state definitions are flexible enough to be able to describe these other rollovers (and I am afraid that the current key state definitions are not). I disagree that seven or eleven documents would be best for operators. Having more than one requires them to know the RFC numbers for all the documents for which they are possibly interested. Other WGs have problems with developers having to know about three RFCs for a protocol; it seems odd to think that us having a dozen documents for operators is a good idea. Long documents are not a problem if they are reasonably well organized with truly parallel sections. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/21/2012 05:53 PM, Paul Hoffman wrote: On Aug 21, 2012, at 12:12 AM, Matthijs Mekking matth...@nlnetlabs.nl wrote: I am afraid that one document just isn't sufficient. Adding a rollover time line requires a fair amount of pages to cover the timing details (at least with the current approach). The current document now covers six time lines. When we want to add time lines for Single Type Signing Scheme, Algorithm Rollover and Policy Rollover, we can come up with about ten more time lines. It would become a very lengthy document, arguably even longer than 4641bis ;). In my opinion, it would be better to categorize them and deal with them over multiple documents (one document per category). We then could use one document which has the base terminology, so we can refer to, for example, the key state definitions in future documents. However, then we have to make sure that the key state definitions are flexible enough to be able to describe these other rollovers (and I am afraid that the current key state definitions are not). I disagree that seven or eleven documents would be best for operators. Having more than one requires them to know the RFC numbers for all the documents for which they are possibly interested. Other WGs have problems with developers having to know about three RFCs for a protocol; it seems odd to think that us having a dozen documents for operators is a good idea. I am not talking about seven or eleven. Although I did not wrote down an actual number, I could foresee three: One for KSK and ZSK rollovers, one for so called CSK rollovers and one for key timings with respect to policy rollovers (including algorithm rollover). Seven or eleven are indeed somewhat ridiculous numbers. Three is okay imho, especially if you put in the base document references to the other ones. Best regards, Matthijs Long documents are not a problem if they are reasonably well organized with truly parallel sections. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQNHSSAAoJEA8yVCPsQCW5f8gH/1JXSWDKr7ZCADlYYP89VlC4 JNmjutD1yXM7k21A34ZJtgyxnXjXhqVwMpJOSZhmtJhaHaDwI86gw5e+teC+xx3a TUmrC2s95FmcY00V8oZx7JjyHLLBmLhVaqUL6QNr/QuSYDPD5afWvQyVdfDMhygY oMuIDla1CXmkZE/ZKTn8eaGmloSCoeYa+xnR9WROTbp3En8NByTcSjwahPtxBHVK vhTlzrBVMk9wdZpzZQJikqaIiWG4UXa7GAG+dZ94ha7prt6unIfeEFA3Z0oIkTXZ tgOCM7OfpLIJ5cInTPl62CP/gTul8zLYVQfKrAGFBPN81BXGresXCBvtcYCCL5g= =Wgsz -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing
On Aug 20, 2012, at 6:19 AM, Peter Koch p...@denic.de wrote: Andrew, In the archives since the meeting, I observe some comments at http://www.ietf.org/mail-archive/web/dnsop/current/msg09783.html. But I do not observe the announcement of a WGLC. I am wondering when we might expect that call. both chairs have taken advantage of the season at least a bit. One of the chairs has recused himself being a co-editor, so this is the document shepherd. Issuing the WGLC involves reviewing the draft as well as the recent discussion to generate framing questions. In this particular case, several members of the WG, some of which I remember having been in favour of WGLC during the Vancouver meeting, had expressed support for a major change to the draft suggested by Matthijs Mekking on July 24 http://www.ietf.org/mail-archive/web/dnsop/current/msg09767.html That would basically mean folding significant parts of 'keytiming bis' into the current 'key timing' draft. That was my (probably biased) memory as well. My current reading of the sense of the WG is that we move to WGLC with -03, declaring the July 24 suggestion out of scope for this document and keep momentum for 'dnssec bis'. That's one way to do it. A better one would be to start WG LC on key-timing with an explicit question to the WG about folding in the keytiming-bis changes. That way, the WG would know the status of both, and we would would possibly produce just one document. The operations community would be better off with just one document, if this WG can do that. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing-00
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/20/2010 01:03 AM, Suzanne Woolf wrote: On Tue, Oct 19, 2010 at 10:22:25AM -0400, Andrew Sullivan wrote: On Tue, Oct 19, 2010 at 10:26:27AM +0200, Johan Ihren wrote: B. Better to publish what we have and initiate work on a -bis document immediately. Also known as the Perfect is the Enemy of Timely-alternative. I like this, but I'd like it more if there were text in the document that said something like, This represents current thinking at the time of publication. The reader is reminded that DNSSEC is as of publication in early stages of deployment, and best practices will likely change in the near term. Or something like that. The idea is to give the reader a clue that s/he ought to be keeping up with the mailing lists and so on in order to understand what is happening. Or even These are the guidelines as best we understand them, as we write, but we expect them to serve partly as a basis for further discussion and experiment. If you find something better, bring it on. Although we have already better understanding for guidelines that are more complete and have improved clarity. So perhaps These are the guidelines as best we understood them ;). But perhaps B is the best option, although minor surgery is still needed before publishing. That includes text like Andrew suggested. Then this document can serve as input for -bis documents. Best regards, Matthijs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMvqk0AAoJEA8yVCPsQCW5pVUH/3xKquLmz1ZPADjKOPx6k4Ad dnLA8j+NCeC+jJjQiNybDQ9fWy0soHuEFvZttsRlZkDeb/ClXhkgB3awGz0mDSNo VfKCT24aZIwHzvZ3T+II0d73NAnFBD/AdeHRE9DBp5HFxzGz23FpJBwfXUP5StFt 9DGpc1ZSE2krv8J6TjfjkZW1OImZaxuvldilnXNzn2qTb1uytziim9nMkVinAN9n tanb6S7S5Z5ihAb1tFLL8xT1Co3B49OBDoT36y29J0OOsPQogJ8naPmlsmK0Iq8h a0g4F3nzPl4kIo45Kqwga1GFdvPbTaOXwubvFqIYVDMIc3hflisHH5V/xtTiILM= =3+ns -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing-00
On 20/10/2010 4:32 AM, Matthijs Mekking wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/20/2010 01:03 AM, Suzanne Woolf wrote: On Tue, Oct 19, 2010 at 10:22:25AM -0400, Andrew Sullivan wrote: On Tue, Oct 19, 2010 at 10:26:27AM +0200, Johan Ihren wrote: B. Better to publish what we have and initiate work on a -bis document immediately. Also known as the Perfect is the Enemy of Timely-alternative. I like this, but I'd like it more if there were text in the document that said something like, This represents current thinking at the time of publication. The reader is reminded that DNSSEC is as of publication in early stages of deployment, and best practices will likely change in the near term. Or something like that. The idea is to give the reader a clue that s/he ought to be keeping up with the mailing lists and so on in order to understand what is happening. Or even These are the guidelines as best we understand them, as we write, but we expect them to serve partly as a basis for further discussion and experiment. If you find something better, bring it on. Although we have already better understanding for guidelines that are more complete and have improved clarity. So perhaps These are the guidelines as best we understood them ;). But perhaps B is the best option, although minor surgery is still needed before publishing. That includes text like Andrew suggested. Then this document can serve as input for -bis documents. Best regards, Matthijs I agree that at this time option B is the best one. I will send editors nits from my review of the document. The disclaimer should be that this document covers only rolling keys of the same algorithm, it does not cover transition to/from/addition/deletion of different algorithm. I would also recommend that this document be published as informational. Olafur ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing-00
On Tue, Oct 19, 2010 at 10:26:27AM +0200, Johan Ihren wrote: B. Better to publish what we have and initiate work on a -bis document immediately. Also known as the Perfect is the Enemy of Timely-alternative. I like this, but I'd like it more if there were text in the document that said something like, This represents current thinking at the time of publication. The reader is reminded that DNSSEC is as of publication in early stages of deployment, and best practices will likely change in the near term. Or something like that. The idea is to give the reader a clue that s/he ought to be keeping up with the mailing lists and so on in order to understand what is happening. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing-00
At 10:22 AM -0400 10/19/10, Andrew Sullivan wrote: On Tue, Oct 19, 2010 at 10:26:27AM +0200, Johan Ihren wrote: B. Better to publish what we have and initiate work on a -bis document immediately. Also known as the Perfect is the Enemy of Timely-alternative. I like this, but I'd like it more if there were text in the document that said something like, This represents current thinking at the time of publication. The reader is reminded that DNSSEC is as of publication in early stages of deployment, and best practices will likely change in the near term. Or something like that. The idea is to give the reader a clue that s/he ought to be keeping up with the mailing lists and so on in order to understand what is happening. +1 to Andrew's addition, and maybe add another one: Some of the techniques and ideas that DNSSEC operators are thinking about that differ from this document include and a list of interesting phrases, no details. --Paul Hoffman, Director --VPN Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing-00
On Tue, Oct 19, 2010 at 10:22:25AM -0400, Andrew Sullivan wrote: On Tue, Oct 19, 2010 at 10:26:27AM +0200, Johan Ihren wrote: B. Better to publish what we have and initiate work on a -bis document immediately. Also known as the Perfect is the Enemy of Timely-alternative. I like this, but I'd like it more if there were text in the document that said something like, This represents current thinking at the time of publication. The reader is reminded that DNSSEC is as of publication in early stages of deployment, and best practices will likely change in the near term. Or something like that. The idea is to give the reader a clue that s/he ought to be keeping up with the mailing lists and so on in order to understand what is happening. Or even These are the guidelines as best we understand them, as we write, but we expect them to serve partly as a basis for further discussion and experiment. If you find something better, bring it on. Sorry guys-- I don't think the parrot is dead enough to get you off the hook. Suzanne ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
