Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt]
On Mon, Feb 13, 2012 at 09:33:05AM +0100, Stephane Bortzmeyer wrote: On Mon, Feb 06, 2012 at 07:12:56PM +, bmann...@vacation.karoshi.com bmann...@vacation.karoshi.com wrote a message of 49 lines which said: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Root Name Server Operational Requirements Author(s) : Root Server System Advisory Committee Filename: draft-rssac-dnsop-rfc2870bis-04.txt Section 3.2.1 : I do not understand why you need synced time for DNSSEC. The root name servers do not generate signatures. but they do use TSIG. And historically, channel protection via TSIG or SIG(0) was considered part of the DNSSEC tool box. Granted that DNSSEC perception has changed over the years. but the need for sync'ed clocks is becuase of TSIG. Section 3.2.1 : Several root name servers, such as B, reply to ICMP echo requests, which I think is a good thing, but it seems disallowed in your document. -I- think its a good idea, but others would prefer less transparency Section 4.2 : This advice directly contradicts RFC 6382. Do you plan to reclassify it as Historic? It meaning RFC 6382? Not really. The draft was an attempt to document current practice - with some leanings toward future directions. Section 5.1 : Announcement of planned outages also keeps other operators from investigated a scheduled maintenance window. My english parser broke here. Should I upgrade it or should you rewrite the sentence? investigated should be investigating. e.g. if you don't tell anyone you are doing maintance work, observers will presume the worst and start to debug why the L root has gone offline. (For the record, I agree with most of Joe Abley's remarks on high-level issues with this document.) There are some strong argumetns for simply stating operational goals/principles vs documenting practice. I beleive that we are working on a mission statement /bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt]
At 21:39 + 2/9/12, bmann...@vacation.karoshi.com wrote: I think that starting work on such a draft is a great idea -BUT- in the mean time do not let perfect get in the way of good enough. I beleive Terry agreed with that line of thnking. Of the existing Operators, A, B, E, G, H, J, L, and M have made positive comments and worked on upgrading this base text provided by one of the Operators. Is your opinion / argument strong enough to stop work on this draft? As David says, why is this document being republished? Is there some deadline? This is a document not code, and not even a first document but a revision. If a revision is not perfect at the time it is published, it's pretty much not worth publishing. Especially an update document - we already have an RFC on this, why update it with another RFC that inaccurately describes the state of the world. My concern is that future RFPs and contracts will cite this as a document to comply with. That is when it becomes my pain, even if the job at hand is not operating a root server. I especially like Joe's point #3. That said, I'd love to see a revamped version, if you have the time to copy-edit/reorgnize the document. I do not recommend publishing the document as is. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt]
On Mon, Feb 06, 2012 at 07:12:56PM +, bmann...@vacation.karoshi.com bmann...@vacation.karoshi.com wrote a message of 49 lines which said: Any more? One governance question. As far as I know (I am not a root name server operator), several of the root name servers already comply with the (very strong) requirments of this document. But not all. If the document is published, what will happen of them? In other words, what is the goal of the document? Exercice some pressure or more? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt]
On 14 Feb 2012, at 16:34, Stephane Bortzmeyer wrote: One governance question. As far as I know (I am not a root name server operator), several of the root name servers already comply with the (very strong) requirments of this document. But not all. If the document is published, what will happen of them? We report them to the Internet Police's Root Server Department. :-) To be less flippant, I would assume that someone who has a concern about root server operations will ask each RSO if their server meets or exceeds the requirements in RFC2870bis and if the answer is no, they'll ask why not. In other words, what is the goal of the document? Exercice some pressure or more? IMO RFC2870bis is probably never going to be aligned with what is actually done to run a real root server. Discussion of some of those practices probably won't be in the public domain for a while anyway. That said, it's good to update and revise those guidelines from time to time. IMO the value of this document is to describe the general principles and suggest to others how an important DNS server should be operated. For instance, it can (and has) been used in RFPs for DNS service for TLDs. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt]
On Feb 14, 2012, at 6:17 AM, Edward Lewis wrote: At 21:39 + 2/9/12, bmann...@vacation.karoshi.com wrote: Is your opinion / argument strong enough to stop work on this draft? As David says, why is this document being republished? A question I'll note has not been answered. My concern is that future RFPs and contracts will cite this as a document to comply with. Agreed. A BCP on how best to provide a highly resilient DNS service would probably be useful. The document in question isn't close. At best, it feels like a bit of self-congradulatory back-patting for those root server operators that actually come close to what the document describes. At worst, it can be seen as an attempt at obfuscation of the fact that the root server operators (with one notable exception) are _NOT_ subject to RFPs, contracts, or any other form of enforcement. That said, I'd love to see a revamped version, if you have the time to copy-edit/reorgnize the document. I do not recommend publishing the document as is. +1 Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt]
On Feb 14, 2012, at 8:56 AM, Jim Reid wrote: I would assume that someone who has a concern about root server operations will ask each RSO if their server meets or exceeds the requirements in RFC2870bis and if the answer is no, they'll ask why not. And if no acceptable answer is provided? Sorry, rhetorical question: can't stop myself from kicking the brown stain that used to be a dead horse. That said, it's good to update and revise those guidelines from time to time. IMO the value of this document is to describe the general principles and suggest to others how an important DNS server should be operated. For instance, it can (and has) been used in RFPs for DNS service for TLDs. I agree, however I'd think a better approach would be to write a BCP for important DNS servers, not a document that sets up false expectations or assumptions. Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt]
On 2/14/2012 5:20 PM, David Conrad wrote: ... I agree, however I'd think a better approach would be to write a BCP for important DNS servers, not a document that sets up false expectations or assumptions. +1. there are a lot of important non-root dns servers, and the collected wisdom of all of there operators would be a good thing to gather and peer-review and publish. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt]
On Feb 14, 2012, at 9:22 AM, Paul Vixie wrote: are you sharing insider knowledge from your time as IANA GM here? Nope. i thought that ICANN and VeriSign were both under enforceable contracts with respect to their role as root name server operators. As far as I'm aware (and happy for any of the root operators to correct me), the only actual contract is between U.S. Dept. of Commerce and VeriSign for the operation of the A (and J?) root server(s). That's part of the irrationality of root service -- it isn't even clear between whom contracts should be. inside baseball warning. the agreement signed between ISC and ICANN on january 23 2008 is not enforceable in that it does not specify any recourse for either party due to any nonperformance by the other party. Yep. We acknowledge you exist, you acknowledge we exist, and we might think about discussing the possibility of perhaps considering doing some undefined stuff someday in the future. Or maybe not. With that said, it was a step in the right direction. Not aware of any further steps, but I haven't been paying attention. Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt]
On Mon, Feb 06, 2012 at 07:12:56PM +, bmann...@vacation.karoshi.com bmann...@vacation.karoshi.com wrote a message of 49 lines which said: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Root Name Server Operational Requirements Author(s) : Root Server System Advisory Committee Filename: draft-rssac-dnsop-rfc2870bis-04.txt Section 3.2.1 : I do not understand why you need synced time for DNSSEC. The root name servers do not generate signatures. Section 3.2.1 : Several root name servers, such as B, reply to ICMP echo requests, which I think is a good thing, but it seems disallowed in your document. Section 4.2 : This advice directly contradicts RFC 6382. Do you plan to reclassify it as Historic? Section 5.1 : Announcement of planned outages also keeps other operators from investigated a scheduled maintenance window. My english parser broke here. Should I upgrade it or should you rewrite the sentence? (For the record, I agree with most of Joe Abley's remarks on high-level issues with this document.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
