Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-algorithm-update
On 10/17/18 11:18 PM, fujiw...@jprs.co.jp wrote: > 4. In my opinion, Ed25519 is best algorithm some yars later. >If the document describes both current RECOMMENDATIONS and >RECOMMENDATIONS some years later, we can plan. I agree, but the last paragraph of 3.1 seems to express that already: > It is expected that ED25519 will become the future RECOMMENDED default > algorithm once there's enough support for this algorithm in the > deployed DNSSEC validators. Do you mean that "expected future recommendations" should be made more visible in a separate section or something? --Vladimir ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-kskroll-sentinel-15: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-kskroll-sentinel-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/ -- COMMENT: -- Thanks for addressing my Discuss points -- the text in the github version of this document helps a lot, and I'm happy with the direction we're going in for the more general case. [original ballot comments preserved below] Other than my Discuss points, I just have a number of essentially editorial nits. Abstract This document specifies a mechanism that will allow an end user and third parties to determine the trusted key state for the root key of the resolvers that handle that user's DNS queries. [...] This wording feels confusing to me; I think what it's trying to say is "the root key(s) that are in use by the resolver" but am having a hard time grouping these words to achieve that meaning. (Is "trust" really necessary to mention, here?) Section 1 RRSIG RRs contain a Key Tag field whose value is equal to the Key Tag of the DNSKEY RR that was used to generate the corresponding signature. nit: Is the RR used to generate the signature, or just the key? o Users may wish to ascertain whether their DNS resolution environment resolvers is ready for an upcoming root KSK rollover. nit: I think there's a singular/plural mismatch or similar here, maybe "environment's resolver"? o Researchers want to perform Internet-wide studies about the proportion of users who will be negatively impacted an upcoming root KSK rollover. nit: "by an upcoming" If a browser or operating system is configured with multiple resolvers, and those resolvers have different properties (for example, one performs DNSSEC validation and one does not), the sentinel test described in this document can still be used, but it nit: this usage of "but" feels a bit misplaced to me, as the thing being warned about is more that the test may produce indeterminate or inconsistent results. Or perhaps that the assumptions it makes may not necessarily hold in the specific environments being described (i.e., "these environments"). makes a number of assumptions about DNS resolution behaviour that may not necessarily hold in all environments. If these assumptions do not hold (such as, for example, requiring the stub resolver to query the next recursive resolver in the locally configured set upon receipt of a SERVFAIL response code) then this test may produce indeterminate or inconsistent results. In some cases where these assumptions do not hold, repeating the same test query set may generate different results. Section 1.1 Please use the RFC 8174 boilerplate. Section 3 I'll note without further comment that we had a long thread on ietf@ relevant to the term "slave resolver". Section 3.1 If the resolver is non-validating, and it has a single forwarder, then the resolver will presumably mirror the capabilities of the forwarder target resolver. Perhaps this is just me misreading the previous paragraph's introduction to what is clearly a more widely known term of art, but in "has a single forwarder" is the thing of which there is only one the "one or more other resolvers" that the "forwarder" is relaying queries to? It's just weird for the word "forwarder" mean a different protocol participant when used as a noun vs. adjective. Or perhaps this is meant to be possessive; the "forwarder's target resolver"? As noted in the directorate review, "use the CD bit" needs disambiguation. Section 4 nit: missing trailing 'r' in the section title Section 4.3 Maybe call out that these are the same general categories of query as in Section 3 but the key tag used is different for some queries? It's also a bit weird to use new notation for this section as opposed to consistent notation between the different types of test. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] A quick update on draft-ietf-dnsop-attrleaf / draft-ietf-dnsop-attrleaf-fix
Hi there, Dave suggested I send this out. draft-ietf-dnsop-attrleaf and draft-ietf-dnsop-attrleaf-fix have completed IESG review. Alissa is holding a DISCUSS position on draft-ietf-dnsop-attrleaf-fix - this can be seen here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf-fix/ballot/ Alissa (and a number of other ADs) feel that each of the (37!) updated documents should be classified into 2.1. (TXT RRset), 2.2. (SRV RRset) or 2.3. (URI RRset). Basically, we need to go through each document in draft-ietf-dnsop-attrleaf-fix, figure out which class it falls into (TXT, SRV, URI), and add it to a list. We then add a sentence to each of those sections saying "Documents in this category include RFC, RFC, RFC". Dave has stated that he is unwilling to do this work. Instead of having the WG document simply stall, Benno and I have agreed that we would split them between us. If anyone would like to volunteer to help out, we would not take it amiss. Please note that this is not a normal situation - in general we expect the authors to deal with IESG DISCUSS (and other ballots) - but we wanted to move this document along. So, if you would be willing to take a few documents to classify, please go to this spreadsheet: https://docs.google.com/spreadsheets/d/1oTs8ZJy6EZdSt4NXZJbcIRd771V9Rbg9TqddE5KlLGE/edit?usp=sharing [0] Change the reviewer from Benno or Warren to your name **before** starting the review (we really don't need multiple reviews of the same document!), and then update the spreadsheet with what "class" of update it is. Please have the review done by Wednesday Oct 24th. Review help would be appreciated, but if you are not able to (I know people are really busy before IETF week), Benno and I will manage... W [0]: Posting a public link to a spreadsheet what could *possibly* go wrong!? -- 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A quick update on draft-ietf-dnsop-attrleaf / draft-ietf-dnsop-attrleaf-fix
On 10/18/2018 12:04 PM, Warren Kumari wrote: Dave has stated that he is unwilling to do this work. Instead of having the WG document simply stall, Benno and I have agreed that we would split them between us. If anyone would like to volunteer to help out, we would not take it amiss. Please note that this is not a normal situation - in general we expect the authors to deal with IESG DISCUSS (and other ballots) - but we wanted to move this document along. (Oh boy. Had Warren merely said something neutral like 'Dave won't be able to do that' I wouldn't feel the need to post this. But given his wording...) Alissa's Discuss is based on an extrapolation of the Update semantic, beyond anything that is documented because, I'm told, the IESG hasn't been able to reach consensus on relevant details. Worse, her concern is that someone editing one of the cited specs will not know which part of the -fix document applies to them. Given the detail that /is/ provided in -fix, IMO the odds of that problem are lower than 'unlikely'. There are 35+ documents cited, so the task that is being imposed is non-trivial. My understanding is that it is not uncommon to have an Updates citation to something like the base Attrleaf document, with no additional detail guiding the update to a cited document. From that perspective, the -fix document is already considerably more detailed than often/sometimes required. I'll also note that I gave this feedback to Alissa directly, earlier and she did not respond to it. That failure to engage is just one more problem with this Discuss. (And it hearkens back to years ago when ADs would do this sort of thing regularly. Not me, of course, but some...) And just to be clear, obviously I'll add whatever text the wg agrees on. My limitation is spending the significant on a task that appears to be entirely unnecessary. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
