Re: [DNSOP] [IANA #1305341] [Errata Verified] RFC8552 (7065)
On 1/22/2024 6:44 PM, Amanda Baber via RT wrote: I'm just writing to note that we put this fix in place last week, after a note from Warren: https://www.iana.org/assignments/dns-parameters dandy. thanks! d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Dealing with some open Errata:
On 1/15/2024 2:49 PM, Paul Wouters wrote: I think this might have been part of a list used to "reserve" the names of (transport) protocols, so that constructs like _25._quic.example.com could be constructed where the _name denotes the protocol and not the name of something. I think dccp got added to this list because it is references as a "transport protocol" in RFC4340 and the author wanted to make sure transport protocol names were not accidentally squatted by newly invented things with a clashing name/acronym. That's a rather more thoughtful and pleasing explanation. I think it is also correct. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Dealing with some open Errata:
On 1/15/2024 2:20 PM, Warren Kumari wrote: These include two Errata filed by Bernie Hoeneisen (author of RFC6118) against RFC8552 - "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves" <https://datatracker.ietf.org/doc/rfc8552/> I'd like to get feedback by Monday Jan 29th, otherwise I'll just go with my proposed resolutions below. Errata1: https://www.rfc-editor.org/errata/eid7066 --- Section 4.1.2. says: | URI | _dccp | [RFC7566] | It should say: ? Notes: Wrong reference. RFC7566 does not even mention "dccp". Unaware of a useful reference. Not sure this line needs to be removed. Note that this also has an impact to the IANA registry: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names —- I **think** that the correct reference for this is actually RFC7553 - "The Uniform Resource Identifier (URI) DNS Resource Record" <https://datatracker.ietf.org/doc/rfc7553/>. Note that this initially confused me, because I was looking for DCCP (and TCP and UDP) in the URI *registry*, not in the DNS RR definition. My proposed resolution: Mark Errata verified, update reference to be RFC7553. I am not finding the string dccp in rfc7553. I looked in the other candidate RFCs and didn't find _dccp in them. Absent affirmative knowledge that this _attribute is in real-world use, the correct action would be to remove it from the registry, IMO. In the alternative -- since it is not exactly damaging or wasting a precious resource -- leave the registration but take out the reference. So it shows as registered, but implies it is there because, well, we felt like it. On reflection, quite a few of the entries were, I think, done for exactly that reason. Or rather, for completeness. Note, for example, that the SRV registration for _dccp points to the SRV RR definition, although that document does not cite dccp. Errata 2: https://www.rfc-editor.org/errata/eid7068: —- Section 4.1.2. says: | URI | _tcp | [RFC6118] | | URI | _udp | [RFC6118] | It should say: ? Notes: Wrong reference. RFC6118 does not even mention "tcp" nor "udp". Unaware of useful reference(s). Not sure this line needs to be removed. Note that this also has an impact to the IANA registry: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names --- My proposed resolution: Same as above. I think that these, two, were cases of wanting completeness in the registrations. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Errata Verified] RFC8552 (7065)
On 1/15/2024 1:32 PM, RFC Errata System wrote: Original Text - | URI| _iax | [RFC6118] | Corrected Text -- | URI| _iax | [RFC6315] | Notes - Wrong reference. Note that is also has an impact to the IANA registry:https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names _iax does not appear in RFC6118, while RFC6315 defines it. So this seems to be correctly identifying an error in RFC8552. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Editorial Errata Reported] RFC8552 (7064)
On 8/9/2022 2:41 AM, ber...@ietf.hoeneisen.ch wrote: 1) There is clear evidence that all the references to RFC 6118 I pointed out in the errata recently filed are incorrect; RFC 6118 does not even mention these labels in question. In addition, RFC 6118 has nothing to do with "transports". As I tried to indicate in my original note to you, the issue I'm raising is not to contest this new -- actually old -- reference, but to note the absence of documentation of the basis for choosing and therefore is not reliably replicable. This choices for this set of citations is not straightforward and so the logic for the choice needs to be clear, not just in an email exchange, but in the RFC. Again, this issue is underscored by the facts that a) the citation now deemed correct was already used once in the table and then rejected, and b) there have been 3 different citations. This means that it is clear that the basis for the choice is not clear. If it isn't clear, it isn't 'interoperable', in terms of producing reliable choices. Unfortunately, I completely missed the process of RFC 8552, While it's always nice to have the author of a relevant document participate, the IETF specification process is not supposed to be so fragile that it is required. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Editorial Errata Reported] RFC8552 (7064)
On 8/8/2022 4:10 PM, John R. Levine wrote: In any event, the underlying references make it quite clear why Bernie's fixes are the right ones. The citation was in the table once before, during document development. And was then changed. Across the drafts, there were /three/ different RFC numbers listed. Absent a clear understanding of why this 'new' one was deemed wrong then, but correct now, making the change now is rather whimsical. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Editorial Errata Reported] RFC8552 (7064)
On 8/8/2022 3:57 PM, John R. Levine wrote: I don't recall that anyone judged it incorrect. I think we just made a clerical error. absent a recollection -- or documentation -- the proffered assessment lacks a basis. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Editorial Errata Reported] RFC8552 (7064)
On 8/8/2022 2:03 PM, Warren Kumari wrote: So, just to be clear, I'm approving all of these errata, yes? As I noted privately, there is a history with this list of RFC references that demonstrates something akin to whimsy, but, at the least indicating a lack of a clear and shared basis for deciding what reference to use. So, for example, why is this latest reference correct this time, when it was judged incorrect, the last time is was used for the entry? That makes it impossible to know whether this latest change really is correct. This time. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Editorial Errata Reported] RFC8552 (7064)
On 8/3/2022 9:48 AM, Tim Wicinski wrote: This seems to be the mail thread which discusses 7566/6118 : https://mailarchive.ietf.org/arch/msg/dnsop/d5KQEP1Ud1TxQpanNMY2_b0CpL8/ that's the second and more substantial thread. The first brief one began with: https://mailarchive.ietf.org/arch/browse/dnsop/?gbt=1&index=XYijqc1aIwHn_pOLZu0RusE9y0U d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Editorial Errata Reported] RFC8552 (7064)
On 8/2/2022 8:04 AM, RFC Errata System wrote: Type: Editorial Reported by: Bernie Hoeneisen Section: 4.1.2. Original Text - | URI| _acct | [RFC6118] | Corrected Text -- | URI| _acct | [RFC7566] | Notes - Wrong reference. Note that is also has an impact to the IANA registry:https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names Folks, 1. Bernie, thanks for bringing this up 2. Using this case as an example, the history in the attrleaf development seems concerning. The RFC cited for this entry changes, over the course of a number of I-D versions. So, in -13 is was RFC 7553, -14 is was RFC 7566, and in -15 it went to RFC 6118. 3. That the published version landed on the wrong choice should raise a question possibly about process but especially about understanding. In Spring, 2018 and again in Fall, 2018, there was some focused discussion (see: dnsop) about _acct, and related strings, and which citation to use for the enum-related values. The choice bounced around, as I've cited. This includes having what is now being deemed the 'correct' choice in -14... Note that none of the cited documents refers to the exact string "_acct". So there is a derivation process that seems to be unclear. I believe the attrleaf RFC contains no pedagogy about this, but it probably should. Before doing the simple -- but possibly wrong -- thing of agreeing on a new -- or, rather, returning to an old -- better RFC citation, I suggest there be some community discussion about the why of the right choice and consideration of how to document that, this time, this latest choice is the truly correct one. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Editorial Errata Reported] RFC8552 (6778)
On 12/7/2021 12:41 AM, RFC Errata System wrote: This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. Verified. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Editorial Errata Reported] RFC8552 (6777)
On 12/6/2021 12:46 AM, RFC Errata System wrote: This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. verified. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Editorial Errata Reported] RFC8552 (6772)
On 12/3/2021 12:35 AM, RFC Errata System wrote: This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. Verified. It is, indeed, a typo. It should be Service4 and not Service 4. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Over on the dbound list: draft-dcrocker-dns-perimeter-00
Howdy. I've posted a draft that might be of interest to folk in this group. It's best venue is almost certainly the dbound mailing list, where it is already starting to get discussion (and cross-posted to the dmarc list.) Discussing it here, on a third list, doesn't seem advisable, but it's already been noted on the dbound discussion that the draft raises issues that might be of concern to the dnsop community. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Editorial Errata Reported] RFC8552 (5665)
On 3/21/2019 4:37 AM, RFC Errata System wrote: This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. Verified. Drat. Good catch. Sigh. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt
On 11/4/2018 7:08 PM, Ray Bellis wrote: On 05/11/2018 09:56, Dave Crocker wrote: So I immediately went to add it and then realized that doing this cleanly will take an entry for each RR... Why not this? ++--++ | RR Type | _NODE NAME | REFERENCE | ++--++ | * | _example | [TBD] | Well, that's two of you making close to the same suggestion (though the version Erik suggested seems a bit more complete. Absent objections, I'll add that. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt
On 11/4/2018 6:28 PM, Erik Kline wrote: One thing I missed earlier (and please forgive me if this was already discussed), was whether or not _example* should be reserved in the table in draft-ietf-dnsop-attrleaf-15#section-4.3. Basically, is there any value in reserving _example* for future RFCs to use (ones that don't care about the specific _foo label but apply to all such labels in some way). Clever suggestion. Seems like obvious benefit with no obvious detriment. So I immediately went to add it and then realized that doing this cleanly will take an entry for each RR... Not so sure we want to do that? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt
On 11/3/2018 4:55 PM, Warren Kumari wrote: I'm also somewhat confused by the quoting in: "In the case of the "SRV" "RR" and "URI" "RR", distinguishing among different types" (and in "defining "RR"s that might" ) - I'm not sure if it is intentional, but it doesn't align with much of the rest of the formatting, and is (IMO) confusing around the first part.) I used spanx too liberally, because it looked nice in the html version on my machine, and I didn't realize what it did for the text version. My use matched what I'm seeing in some bibxml entries, but you are right that it doesn't look right in some of the sequences here. So I've removed most spanx occurrences in the source. Also nit (I think): Adam Roach, Petr Špaček, Ondřej Sury This is a dilemma. The characters produce appropriate text in html, to show his actual name. The xml2rfc text rendering engine produces this silliness and I'm inclined to class it as a bug in the engine. If there is an established practice for working around that bug, to produce the proper characters in html and an 'acceptable' alternative in text, please let me know and I'll fix it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Attrleaf revisions
I have new drafts ready and will submit them on when the submission block is lifted. Copies including diffs are at: https://www.dropbox.com/sh/cwtztpjzauri3i3/AABbexI4p6sC50z-DEVh1tx9a?dl=0 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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/19/2018 3:05 AM, Alissa Cooper wrote: 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...) Could you point out which message I did not respond to? After your last message in the thread about my DISCUSS we had the telechat and from my discussion there with Warren it seemed we had agreed on a way forward, which seemed more appropriate for him to communicate back than for me to. Alissa, Thanks for asking. My wording was too facile, because I was frankly trying to avoid getting into the detail. More accurate wording would have that you responded once, superficially and inaccurately, and then failed to respond. The exchange was: 1) On 10/10/2018 7:52 AM, Alissa Cooper wrote: DISCUSS: I think this document needs to state explicitly which updates apply to which existing RFCs. That is, I would expect to see in sections 2.1, 2.2, and 2.3 the list of which documents are updated by each section. I realize this can be intuited, but typically for avoidance of doubt authors specify precisely which updates apply to which documents. This will also clear up the unused references that idnits is pointing out 2) On 10/10/2018 11:32 AM, Dave Crocker wrote: What is the downside of using the existing text, as compared against the effort (and delay -- quite possibly infinite) caused by requiring development of the considerable detail that you are calling for? My question is not about the difference in cleanliness but about serious, practical risk. 3) On 10/10/2018 11:48 AM, Alissa Cooper wrote: I think the downsides are (1) people reading the documents updated by this document are confused about which parts of the update apply, and (2) it sets a precedent that one RFC can update another without > being specific about what is being updated. I’m not asking for considerable detail, I’m asking for each of 2.1, > 2.2, and 2.3 to specify which documents out of the list in the Updates > header they update. 4) On 10/10/2018 12:16 PM, Dave Crocker wrote: > So by my count, that requires going over roughly 35 documents (again) > to audit and document this additional detail. > > My guess is that the burden on someone updating one of those > documents, seeing the reference to -fix, and being able to properly > determine whether their document revision needs to attend to the > section on TXT RRset usage and/or SRV RRset usage and/or URI RRset > usage is minimal, and the risk of their getting it wrong is zero. and THEN you stopped responding. Above, I say 'superficially' because the two reasons you gave are intuitively appealing but lack the effort needed to balance against cost. That is, they are easy, pro forma tags, appealing in the abstract. Casually deciding to add a task that is likely to take hours -- for someone you aren't paying to do the work -- is problematic, absent serious benefit. This task doesn't come close. I say 'inaccurately' on several counts. First, consider the format and content of the -fix subsections of concern here. Any editor who is revising one of the cited documents and can't figure out which of the 3 sub-sections applies to their document has bigger problems. (Alternatively if folk really believe this is a decision moment that has any serious likelihood of the editor's making an error, we need to word those subsections better.) Second, the assertion of 'precedent' presumes a policy that doesn't exist, as I had noted. Worse, I fear you haven't reviewed all prior RFCs that did updating, to establish that it is at least a de facto policy. But while ad hoc assertion of a non-existent policy is serious in the abstract, it is a minor point compared to the reality of this particular draft: I am pretty sure we have never had an RFC that updated 35+ other documents. Even better is that you are not calling for these subsections to match the precise and complete string-editing style typical for updating RFCs, since that would require 35+ subsectons and dramatically more work. In other words, pragmatics require that this draft already be distinct, so citing 'precedent' fails on the facts. That is why your not responding further was problematic. The latter part of your latest note (quoted at the beginning of this message) points to a larger issue that I'm sure no one wants to pursue, namely the idea that an IESG discussion away from the working group and the author can make absolute decisions with no further discussion or recourse. No matter how excellent the AD, they aren't a principal actor for the work being discussed. Late-stage review and suggestions often produce significant be
Re: [DNSOP] A quick update on draft-ietf-dnsop-attrleaf / draft-ietf-dnsop-attrleaf-fix
On 10/19/2018 7:19 AM, John Levine wrote: Me neither. I wonder if some of these are left over cruft from earlier revisions that included service names. I also believe they are leftovers, due to my not having done the final audit I mentioned after Adam noted them, when I posted the current drafts quickly, so the IESG could have them. (I still have to do that audit.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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
Re: [DNSOP] draft-ietf-dnsop-attrleaf-* drafts latest revisions
On 10/12/2018 9:23 AM, Bob Harold wrote: Sorry to ask this here, but looking at those links, I cannot find a "diff" link anywhere. (I found it in the other emails, but would like to know how to get there from the pages above.) The official announcement emails do contain a direct link to diffs. I sent a pointer to the base datatracker page for the document. To get to the diffs, from such a page, click on the 'History" tab (next to Email expansions.) Then click "Submit". d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-fix-05.txt
On 10/12/2018 9:16 AM, Bob Harold wrote: The "Updates" lists should be sorted, so changing 3921 to 6121 means the whole list gets rearranged. And some people think OCD is a problem. They are s wrong... In other words, thanks. Will do. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Spencer Dawkins' Discuss on draft-ietf-dnsop-attrleaf-fix-04: (with DISCUSS)
On 10/11/2018 8:01 AM, Warren Kumari wrote: I just arrived in Amsterdam, and am somewhat bleary, but I'm not sure I understand your question / point -- is it simply normalizing the IANA language? Offlist he explained to me that the main concern was a normative requirement, without the specification detail to be sure to satisfy it. The issue was rendered moot by the removal of the normative language from that draft. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-attrleaf-* drafts latest revisions
On 10/10/2018 10:50 PM, Adam Roach wrote: Just to make sure you catch them in your audit, the following entries are still missing from the table: Thanks, Adam! d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-ietf-dnsop-attrleaf-* drafts latest revisions
Folks, Based on the latest round of comments, I've submitted revised versions of the two drafts, mostly so that their diffs would be easily obtained. I didn't do the careful, fine-grained review and audit of the changes that will be needed, since I-D numbers are cheap and I figured convenient access to the diffs from today's mounds of changes would be useful for the IESG session. The datatracker entries are: DNS Scoped Data Through "Underscore" Naming of Attribute Leaves https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/ and DNS Attrleaf Changes: Fixing Specifications with Underscored Node Name Use https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf-fix/ d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-attrleaf-fix-04: (with COMMENT)
On 10/10/2018 2:09 PM, Benjamin Kaduk wrote: One other comment, in Section 3.1: Why is the new text only placing a "SHOULD be registered" requirement, as opposed to MUST? It permits use-before-registration, which avoids registration as a barrier to adoption. There is essentially no real risk incurred by this, noting that the semantics of SHOULD translates into "you really must do this, unless you are very knowledgeable and careful about why you aren't doing it right now.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Spencer Dawkins' No Objection on draft-ietf-dnsop-attrleaf-13: (with COMMENT)
On 10/10/2018 4:38 PM, Paul Vixie wrote: i can live with that. which is one heck of a lot of "resource record types" in the same, short paragraph. truth hurts. mumble. drat. that's two in favor, which for this topic rates as overwhelming consensus. sigh. k. if you insist... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Spencer Dawkins' No Objection on draft-ietf-dnsop-attrleaf-13: (with COMMENT)
On 10/10/2018 3:40 PM, Spencer Dawkins wrote: Spencer Dawkins has entered the following ballot position for draft-ietf-dnsop-attrleaf-13: 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-attrleaf/ -- COMMENT: -- This is a DNS specification that is fairly clear to people who know a little about DNS, but not a lot. You win. This text DNS data semantics have been limited to the specification of particular resource record types, on the expectation that new ones would be added as needed. would have been clearer for me, if it said "new resource record types would be added as needed". "new ones" was vague enough to break my train of thought. Long day, late in the afternoon, lots of comments preceding yours, and I appear to be approaching a threshold of pissiness (which I figure you are a far more pleasant target of than any number of the day's predecessors.) So I'm going to nitpick your nitpicking... The current text is: DNS data semantics have been limited to the specification of particular resource record types, on the expectation that new ones would be added as needed. Unfortunately, the addition of new resource record types has proven extremely challenging, over the life of the DNS, with significant adoption and use barriers. which I believe is fully clear, given that there does not appear to me to be any candidate for intepreting 'one' other than 'resource record type', but worse, making the change you suggest would produce: DNS data semantics have been limited to the specification of particular resource record types, on the expectation that new resource record types would be added as needed. Unfortunately, the addition of new resource record types has proven extremely challenging, over the life of the DNS, with significant adoption and use barriers. which is one heck of a lot of "resource record types" in the same, short paragraph. grrr... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-attrleaf-13: (with COMMENT)
Eric, On 10/9/2018 7:23 PM, Eric Rescorla wrote: However some services have defined an operational convention, which applies to DNS leaf nodes that are under a DNS branch having one or more reserved node names, each beginning with an _underscore. The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain, above the underscored branch. This specification explores the nature of this This text is a bit hard to parse for the layman. Here's my attempted rewrite, which captures what I think this means. Conventionally, this construct associates data with the parent domain, with the underscored label instead denoting the type of the data. I'm not sure if that helps, but perhaps something along these lines? Yeah, this has been an oddly challenging bit of text to formulate. Perhaps: However some services use an operational convention for defining specific interpretations of an RRset, by locating the records in a DNS branch, under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with an _underscore. S 1.1. 1.1. Underscore Scoping As an alternative to defining a new RR type, some DNS service enhancements call for using an existing resource record type, but specify a restricted scope for its occurrence. Scope is meant as a I think I get why you are saying "scope" here, but it's kind of not that good fit with the programming concepts of scope as I am familiar with. So I took your concern as an excuse to review the CS definition and find that I still think its application here is appropriate... And it has not seemed to cause confusion for others. S 2. ++ Examples of Underscored Names Only global underscored names are registered in the IANA Underscore Global table. so just for clarify, in the examples above, only _service[1-4] and _authority would need to be registered? Yes. (And I've added a sentence noting that point, for clarity. Thanks.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Alissa Cooper's Discuss on draft-ietf-dnsop-attrleaf-fix-04: (with DISCUSS and COMMENT)
Alissa, On 10/10/2018 2:48 PM, Alissa Cooper wrote: On Oct 10, 2018, at 2:32 PM, Dave Crocker wrote: On 10/10/2018 10:52 AM, Alissa Cooper wrote: I think this document needs to state explicitly which updates apply to which existing RFCs. That is, I would expect to see in sections 2.1, 2.2, and 2.3 the list of which documents are updated by each section. I realize this can be intuited, but typically for avoidance of doubt authors specify precisely which updates apply to which documents. This will also clear up the unused references that idnits is pointing out. What is the downside of using the existing text, as compared against the effort (and delay -- quite possibly infinite) caused by requiring development of the considerable detail that you are calling for? I think the downsides are (1) people reading the documents updated by this document are confused about which parts of the update apply, and (2) it sets a precedent that one RFC can update another without being specific about what is being updated. I’m not asking for considerable detail, I’m asking for each of 2.1, 2.2, and 2.3 to specify which documents out of the list in the Updates header they update. So by my count, that requires going over roughly 35 documents (again) to audit and document this additional detail. My guess is that the burden on someone updating one of those documents, seeing the reference to -fix, and being able to properly determine whether their document revision needs to attend to the section on TXT RRset usage and/or SRV RRset usage and/or URI RRset usage is minimal, and the risk of their getting it wrong is zero. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Alissa Cooper's Discuss on draft-ietf-dnsop-attrleaf-fix-04: (with DISCUSS and COMMENT)
On 10/10/2018 10:52 AM, Alissa Cooper wrote: I think this document needs to state explicitly which updates apply to which existing RFCs. That is, I would expect to see in sections 2.1, 2.2, and 2.3 the list of which documents are updated by each section. I realize this can be intuited, but typically for avoidance of doubt authors specify precisely which updates apply to which documents. This will also clear up the unused references that idnits is pointing out. What is the downside of using the existing text, as compared against the effort (and delay -- quite possibly infinite) caused by requiring development of the considerable detail that you are calling for? My question is not about the difference in cleanliness but about serious, practical risk. I would also like to understand why this is going for BCP. There is effectively no shepherd write-up for this draft (it's just a copy of the write-up for draft-ietf-dnsop-attrleaf and talks about this document as the "companion" document) so there is no explanation there. One effect of this being BCP is that it adds a huge number of documents to the downref registry. It's not clear to me that the upside of that is bigger than the downside. I've no comment about status choice. Concerning the shepherd writeup, I'm not understanding what problem(s) it is causing. I gather that your main point is that making this Proposed would be better? Sections 2.1, 2.2, 2.3: I don't understand why the paragraphs "If a public specification that defines ... MUST be entered into this registry, if it is not already registered" are needed, since the same normative requirement is generically stated in draft-ietf-dnsop-attrleaf. Good point. I've changed those 3 bits of text to a commentary form: Note that a public specification, which defines use of an RRset and calls for the use of an underscore-prefixed domain name, its global underscored name -- the one closest to the root -- is required to be entered into this registry, if it is not already registered. target="Attrleaf">. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Alissa Cooper's No Objection on draft-ietf-dnsop-attrleaf-13: (with COMMENT)
On 10/10/2018 12:54 PM, Alissa Cooper wrote: The Gen-ART review for attrleaf is athttps://mailarchive.ietf.org/arch/msg/dnsop/dq-cwawY1UqoGJWFUxQPuWv0oPc. hmmm. I see that its addressing should have reached me but I'm not finding a copy in my mail archive. Thanks for the pointer: From: Erik Kline To: Cc: dnsop@ietf.org, i...@ietf.org, draft-ietf-dnsop-attrleaf@ietf.org Message-ID: <153799182298.21553.7443559303630152...@ietfa.amsl.com> Date: Wed, 26 Sep 2018 12:57:03 -0700 Subject: [DNSOP] Genart last call review of draft-ietf-dnsop-attrleaf-13 Section 2: "DNS nodes names" doesn't quite scan for me. "DNS node names" perhaps? Section 4.2: s/simply/simplify/? Section 5: s/in the of/in the/? done. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Alissa Cooper's No Objection on draft-ietf-dnsop-attrleaf-13: (with COMMENT)
On 10/10/2018 10:03 AM, Alissa Cooper wrote: I agree with Alexey. It seems like the expert is being asked to do the review that IANA would typically do itself. Point taken. However, there was wg discussion about the choice and it landed on this. I'll await either wg or iesg direction for specific text changes to the draft on this. Please address the Gen-ART review nits. Did that some time ago, though I believe I did not receive a followup response: Forwarded Message Subject: Fwd: Re: Genart last call review of draft-ietf-dnsop-attrleaf-fix-04 Date: Wed, 26 Sep 2018 13:29:07 -0700 From: Dave Crocker To: draft-ietf-dnsop-attrleaf-...@ietf.org G'day. Just for completeness... Absent direction to the contrary, I'm making no changes concerning the following items (with the ones that have produced changes elided): (BTW, I can't find documentation that explains the sub-addressing scheme for sending to folk associated with an internet-draft, and I don't remember the details of the various choices. So I dropped the .all in case it meant the entire wg. /d) Forwarded Message Subject: Re: Genart last call review of draft-ietf-dnsop-attrleaf-fix-04 Date: Mon, 24 Sep 2018 06:16:13 -0700 From: Dave Crocker To: Francesca Palombini , gen-...@ietf.org ... On 9/24/2018 3:00 AM, Francesca Palombini wrote: The use of underscored node names is specific to each RRTYPE that is being scoped. As an non-expert in the area, I would have appreciate a ref to a document introducing RRTYPE. The term is basic to DNS, with RFC 1035 cited in the first sentence of the Introduction: "Original uses of an underscore character as a domain node name [RFC1035] prefix, which creates a space for constrained interpretation of resource records, were specified without the benefit of an [IANA-reg] registry." Once such a citation has been included, is a document expected to repeat the citation for every term used from it? The implication is that someone reading this sort of document is not expected to have basic DNS familiarity? However this did cause me to look for the first use of "RRTYPE" and I discovered that RFC 1035 has "RR TYPE" but not "RRTYPE". I'm not sure where first use without the space started. This section provides a generic approach for changes to existing specifications that define straightforward use of underscored node names, when scoping the use of a "TXT" RRset. Same for "TXT" RRset. Same response. An effort has been made to locate existing drafts that do this, register the global underscored names, and list them in this document. Since the effort has been done, I would have appreciated the full list here. This is the 'fix' document, not the registry definition document. The latter is cited in the first paragraph of this document's Introduction: "A registry has been now defined, and that document discusses the background for underscored domain name use [Attrleaf]." That's where the list is provided. An effort has been made to locate existing drafts that do this, register the global underscored names, and list them in this document. Same as previous comment. Same response. An effort has been made to locate existing drafts that do this and register the associated 'protocol' names. Same as previous. Same response. ... + Those registered by IANA in the "Service Name and Transport Protocol Port Number Registry [RFC6335]" Move the end quote after Registry. ok. Good catch. /// 9/26: As I posted to the wg, these actually appear to be a bug in the xml2rfc processing tool at the IETF site. I've made changes to the document to work around it. /d John Levine, Bob Harold, Joel Jaeggli, Ondřej Sury and Paul In Acknowledgements, one name is not encoded correctly. I believe this as a bug in the xml2rfc generator used by the tools site, for text format, since the correct text is produced by an xml to html generator. /// 9/26: This also appears to be a tool bug. /d From running the idnits tool (https://tools.ietf.org/tools/idnits/), several comments, warnings and one error were raised, which I snipped and pasted below as a summary: What's most interesting here is that the document passed IDNits during submission! (Apparently nits only works on txt documents and I only submitted an xml version; I'd guess the submission process does not general a txt version on the fly, for nits to inspect...) -- The draft header indicates that this document updates RFC, but the abstract doesn't seem to mention this, which it should. (see https://www.ietf.org/id-info/checklist) --> I see that the abstract generally mentions "
Re: [DNSOP] Adam Roach's No Objection on draft-ietf-dnsop-attrleaf-fix-04: (with COMMENT)
On 10/10/2018 11:52 AM, Adam Roach wrote: I think this reply covers everything that warranted a specific response except for the questions in the following three comments, which are asking specifically about URI RRs: Drat. Sorry. I'll blame it on limited screen real estate while traveling, impeding a careful audit... Comment 1: Was the removal of "web" intentional? I believe it was not intentional. I've added it to the draft because I can't think of a downside to its being there... Comment 2: These initial entries misspell "xmpp" as "xmp" ack. Comment 3: Is it envisioned that all future URI entries in this table will reference RFC 7533? That doesn't quite seem right. My instinct is that it would serve the users of this registry better if: - _iax refers to RFC 6315 - _acct refers to RFC 7566 - All other enumservice-based URI entries in the current table refer to RFC 6118 - RFC 7533 is mentioned elsewhere in the document as the reason enumservices appear in the table. Hmmm. I like your last bullet, as a way of choosing between citing definition of the RR vs definition of the name. Thanks! d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adam Roach's No Objection on draft-ietf-dnsop-attrleaf-fix-04: (with COMMENT)
Responding to your additional comments...
On 10/8/2018 11:43 PM, Adam Roach wrote:
Echoing comments from my review of draft-ietf-dnsop-attrleaf: I believe this
document needs to also include RFC 6763 and RFC 4386; and that it should not
include RFC 6733. Please see that review for details.
RFC 6733 (Diameter):
Section 5.2 #3 cites SRV usage with underscore details. So it
should remain in -fix, to trigger review of this text if/when the spec
is revised.
However the entry in the base table, citing it, should be removed,
because the RFC 6733 _tls text is an example and not a spec.
RFC 6763:
Wow. Whole new RR category for the table, for PTR usage (in the
base spec, as well as -fix.)
If I am reading 6763 correctly, in terms of 'global' underscored
use and distinguishing its 'hypotheticals' from actual usage, it only
reserves _tcp and _udp. (For example, its use of _ipp is second-level
and therefore not global.)
RFC 4386:
SRV usage. So, yeah, it's in -fix.
§§2.1 and 2.2:
An effort has been made to locate existing drafts that
do this, register the global underscored names, and list them in this
document.
I think this text ("list them in this document") is left over from before this
document was split from draft-ietf-dnsop-attrleaf.
oops. However I think it useful to highlight the possibility of names'
having been missed in the initialization of the registry -- and your
review here has nicely demonstrated the issue... -- so rather than drop
that sentence, I've modified it to:
An effort has been made to locate existing drafts that do this,
register the global underscored names, and list them in the initial
set of names added to the registry.
§2.3:
This ties back to my discuss on draft-ietf-dnsop-attrleaf, and needs to be
changed in a way that is consistent with however that issue is resolved. The
current list of entries added by draft-ietf-dnsop-attrleaf strongly implies that
the contents of https://www.iana.org/assignments/enum-services were
automatically imported into the namespace created by the Underscore Global
Registry by the simple existence of RFC 7553. If that's the case, it seems that
the following text in this document...
For any document that specifies the use of a "URI" RRset
...doesn't capture the real process here. As RFC 7553 will continue to exist
into the future, it seems that the trigger is addition of new Enumservice
entries, rather than the explicit specification of a new URI RRset.
Given the choice of de-coupling maintenance of the tables, there is no
goal to make an entry into the underscore table for each new name in
enumservice. Rather there is a need to make an entry in the underscore
table for every URI use of a new underscore entry.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-attrleaf-fix-04: (with COMMENT)
On 10/10/2018 8:43 AM, "Mirja Kühlewind (IETF)" wrote: However re-consider the appropriate intended status for this doc! I assume that is still something that the IESG resolves, independent of whatever is on the draft. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-attrleaf-fix-04: (with COMMENT)
On 10/10/2018 7:26 AM, Mirja Kühlewind wrote: I don't quite understand why it was seen as beneficial by the group that this doc has been split up, Did you see the note I posted yesterday about this (in the context of having the base refer to the -fix, but including an explanation for the split)? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adam Roach's Discuss on draft-ietf-dnsop-attrleaf-13: (with DISCUSS and COMMENT)
On 10/9/2018 3:33 PM, Adam Roach wrote: That's a fair point. I still believe that this arrangement makes the situation as it pertains to URL RRs worse rather than better, but I'm willing to call myself in the rough here. If another AD sees fit to DISCUSS this issue, I will support them. But I'll clear my own discuss now, as it seems that we've reached a difference of opinions regarding harm rather than demonstrable harm. Thanks! d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adam Roach's Discuss on draft-ietf-dnsop-attrleaf-13: (with DISCUSS and COMMENT)
On 10/9/2018 2:45 PM, Adam Roach wrote: This is based on an assumption that document authors who add enumservices are more likely to notice the need [1] to add their service name to two tables than the IANA are. Given the respective levels of rigor, that seems like a losing bet. There is certainly a substantive discussion to have about this, since the working group did. But I'll suggest something simple, in the hope that it actually simplifies things in process terms: This issue was discussed at some length within the working group, including disagreements of the sort you raise now. Eventually the working group finally settled on the choices made in the draft. That is, this is a matter of some tradeoffs that the working group considered. d/ ps. FWIW Personal comment: having to coordinate tables based the SRV spec is unfortunate. Thinking about having to factor in the URI details pretty much blew me by the fact of it's using /two/ tables and how it used them. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adam Roach's Discuss on draft-ietf-dnsop-attrleaf-13: (with DISCUSS and COMMENT)
On 10/8/2018 10:15 PM, Adam Roach wrote: My top-line concern is that, while the table established by this document appears to intend to be a strict superset of the Enumservices table, there are no instructions of any kind to the IANA that would result in these tables remaining in sync -- that is, when a new service is added to the "Enumservice Registrations" table, one might presume that it needs to also appear in the new registry established by this document. Adam, Ongoing dependence on these other tables was the original model, and for a long time. It is not the model now. A major motivation for making this change was exactly to avoid the synchronization challenge you note. So the round of effort that produced the document split to a base and and a -fix also produced a change in the use of the independent tables. The current specification /eliminates/ dependence on these other tables. The goal has been to register all the names that are known to be used, from the various other tables, and then modify the specs that were originally written using those other tables to, instead, require making further additions directly and only to the _underscore registry. There was quite a bit of discussion about the challenge of synchronization. This was not helped by the fact that the IANA folk are so accommodating and expressed a willingness to attempt to keep things in sync. However it isn't reasonable to task them with that on-going synchronization effort: it's certain to fail at some point. So instead we eliminated the requirement. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Genart last call review of draft-ietf-dnsop-attrleaf-fix-04
Henrik, Thanks for the quick followup... On 9/26/2018 1:08 PM, Henrik Levkowetz wrote: I think xml2rfc does the right thing. The quotes are provided by you, the author, not the processor, and you've enclosed the element completely in the quotes: yeah, sorry. played with the combinatorials a bit more and agree. xml2rfc is not a do-what-I-mean-not-what-I-say piece of code quite yet ,;-) well, now, that's something to work on. d/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Genart last call review of draft-ietf-dnsop-attrleaf-fix-04
On 9/24/2018 6:16 AM, Dave Crocker wrote: + Those registered by IANA in the "Service Name and Transport Protocol Port Number Registry [RFC6335]" Move the end quote after Registry. ok. Good catch. Interesting. Just discovered that this probably qualifies as a bug in the xml2rfc processor tool at the IETF site. (I only submitted the xml, which I think is formally ok.) Here's the xml for that paragraph: Those registered by IANA in the "Service Name and Transport Protocol Port Number Registry" The underscore is prepended to the service parameters to avoid collisions with DNS labels that occur in nature, and the order is reversed to make it possible to do delegations, if needed, to different zones (and therefore providers of DNS). (I'm changing the xml to avoid this bug for the next version.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Genart last call review of draft-ietf-dnsop-attrleaf-fix-04
tandards track status, it is a normative reference to this document. -- Obsolete informational reference (is this intentional?): RFC 3921 (Obsoleted by RFC 6121) Ack. Not intentional; just an error introduced by 12 years of lag time... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-13.txt
On 8/21/2018 11:15 AM, John Levine wrote: It looks fine except that section 6.1 on wildcards vs. underscores is gone. Was that deliberate? I don't recall anyone complainging about it. Moved to Section 1.4. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-fix-04.txt
On 8/21/2018 11:10 AM, Bob Harold wrote: Minor typo: "Specifiction" -> "Specification" that might have been a freudian slip. that, and the spelling corrector must not have looked into xml attributes. sigh. thanks! d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-13.txt
Folks, Just posted the revised base and fix attrleaf documents. I tried to fold in all of the suggested changes. I've checked both documents but would appreciate a separate audit, to make sure... d/ A new version of I-D, draft-ietf-dnsop-attrleaf-13.txt has been successfully submitted by Dave Crocker and posted to the IETF repository. Name: draft-ietf-dnsop-attrleaf Revision: 13 Title: DNS Scoped Data Through "Underscore" Naming of Attribute Leaves Document date: 2018-08-21 Group: dnsop Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-ietf-dnsop-attrleaf-13.txt Status: https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/ Htmlized: https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-13 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-13 -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt
On 7/25/2018 10:59 AM, Bob Harold wrote: Dot "." has special meaning in DNS, so I would prefer: _ta-* Not regex, but a common wildcard usage. wfm. anyone else care to chime in? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt
On 7/25/2018 10:59 AM, Bob Harold wrote: Dot "." has special meaning in DNS, so I would prefer: _ta-* Not regex, but a common wildcard usage. wfm. anyone else care to chime in? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt
On 7/25/2018 2:32 AM, Mats Dufberg wrote: _ta- should go into table 2 on page 9 of draft-ietf-dnsop-attrleaf. Wow. This is a unique case, since it reserves essentially all of an even-more-subordinate namespace -- everything to the right of that dash. Theoretically it isn't that inclusive but in practical terms, unless we want complex pattern-matching for sub-strings at run-time, it is. I'm inclined to have the notation be: _ta-.* to draw from regex, with an explicit reference to that, unless folks agree on something else. (Yes, that's 'pattern matching' but it's in the specification document, not the operational code.) Thoughts? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt
On 7/25/2018 6:25 AM, Tim Wicinski wrote: /no/ changes to the spec, except to correct the typo Bob Harold spotted. Correct? darn. i was trying to be clear that the note referred only to that specific exchange. the . typo is fixed. I'm also adding the other underscored names folks have been citing. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt
For completeness: Absent further discussion and agreement in the wg, I taking this exchange as producing /no/ changes to the spec. d/ On 7/24/2018 7:58 AM, John Levine wrote: In article <9da145f4-df6a-4bfa-b3c9-56027b228...@iis.se> you write: -=-=-=-=-=- In table 2 on page 9, the draft refers to RFC 2782 for _dccp and _sctp (SRV), but those “_node names” are not even mentioned in the RFC. Are they defined elsewhere? RFC 2782 says that SRV's are named with _proto where proto is is a protocol name. RFCs 3588 and 6733 say to do _sctp SRV lookups, but don't further define them, and only have 2782 as an informative reference. No RFC mentions _dccp. It seems to me that 2782 is the right reference for _sctp. For _dccp we've had arguments about whether 2782 says that a SRV can be named by any protocol so maybe we should put in every protocol in the IANA registry. That's a lot of dead protocols. A reasonable compromise would be to start the registry with the names that have some evidence of being used somewhere, so we could drop _dccp In the same table, the draft refers to RFC 7553 for a number of URI _node names, but the references are quite indirect. Could references to relevant IANA registries be added? Since RFC 7553 is the place that says that the enumservice names turn into _node names, I think that's the right reference. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-12.txt
On 7/23/2018 2:22 PM, Tim Wicinski wrote: ooks like a typo. That has been there for a bit. ... The table on page 6 includes: "._protoB._service2" Given that it's the only one like that, yes, it should be changed. Just to bikeshed the issue, note that it's not 'wrong' to have the dot there, given the nature of this registration activity and therefore the context that the examples are going to get used in. But certainly things need to be consistent and that one isn't. Thanks for catching it, Bob. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-ietf-dnsop-attrleaf
On 7/18/2018 9:28 AM, Murray S. Kucherawy wrote:
On Wed, Jul 18, 2018 at 12:21 PM, Dave Crocker <mailto:d...@dcrocker.net>> wrote:
Folks,
I'm responding to Murray's impressive proofreading details offlist,
but there are some points he raises that might need wg discussion:
Aw shucks.
COMMENT:
The text specifically calls for a stable reference. Do we have
guidance about what constitutes such a thing? I believe IANA has
its own guidelines to that end; are they available to the
Designated Expert?
I'm inclined to let IANA raise this if they see and issue and then
let them drive the resolution of this point.
Yeah, I don't have the right answer either, but I'm concerned that we're
asking the DE to make a decision with guidelines she doesn't have (or
worse, come up with some that are not consistent with what IANA usually
does).
Section 6:
COMMENT:
I have doubts that SECDIR would accept this one-sentence
comment. I suggest saying something more specific, like:
"This document establishes a registry, and encourages a slight
reorganization of attributes stored in the DNS. It establishes
no new security issues."
The first clause is redundant and makes sense to have here only
either if the readers of this section haven't read the rest of the
document, or if the clause is useful to what follows. I believe
neither applies here.
I imagine myself as a SECDIR reviewer, and believe this would be the
first section I would read for any document to which I'm assigned.
Discovering there a sentence that basically says "None" would get my
back up ("We'll see about that!").
More generally, I have had success with my proposed tactic in the past,
so I thought I'd suggest it here.
I've gotten decreasingly tolerant of using gambits in a specification
document, in order to maneuver through the process. I think the document
should say what it needs to to do its job and not have material that is
primarily for appeasement those in charge. Gambits add cruft, and often
mislead the reader into thinking there is substance when there isn't.
(I think I hit my limit when we appeased an AD for KIM and added the
requirement for the DKIM signature cover the From: field, thereby aiding
in community misunderstanding of what DKIM does.)
If the suggested change had any actual substance with respect to
security issues, that would be quite a different matter. But it doesn't.
Obviously if the wg would prefer different language, we'll use it...
I don't understand the 'encourages' statement but suspect I don't agree.
Reading the document, I got the impression that in your research you
discovered some underscore names that don't quite follow the proposed
placement. If my inference is wrong, then so is that clause.
sorry, but apparently something is getting in the way of my
understanding this issue. Now I'm confused about the 'placement'
reference.
Anyhow, the only problematic, existing specs, I think, are the SRV and
URI documents, because they create naming complexities that invite
problems. Especially the two-source approach that the URI spec has.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-ietf-dnsop-attrleaf-fix
On 7/18/2018 8:37 AM, Murray S. Kucherawy wrote: Section 3.2 replaces text in Section 4.1 of something, but I don't know what; the prior paragraph refers to multiple other documents. I suggest: (a) clarify which document's 4.1 is being replaced, and (b) don't bother including the original (replaced) text. I'll add reference to the RFC being modified, closer to the modification text, but I'd rather keep the old language in there, to reduce the likelihood that someone will replace too-much/not-enough of the existing text. I believe Section 4 can include a note to the RFC Editor to remove it prior to publication. oh? Section 5, as in the other document, is too terse. I suggest summarizing the fact that the only thing going on here is creating of IANA requirements on future work, and updating old documents to reference those requirements. Same reaction as for the other document. I think it the change creates a 'form' of greater substance but not the substance of substance. It doesn't allow a security reviewer to do a better (or worse) job and it doesn't demonstrate meaningfully greater security knowledge of the writer... Side note: FWIW I am certainly concerned that this section be meaningful. When it was first required by the IAB, we were given no guidance about what to include and had no skill at knowing/guessing. So pro forma language, similar to what I've put in, was the norm. In most cases, it represented conformance to form but had no substance. However in the current case, I believe it exactly summarizes the issue for these documents. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-ietf-dnsop-attrleaf
Folks, I'm responding to Murray's impressive proofreading details offlist, but there are some points he raises that might need wg discussion: On 7/18/2018 8:17 AM, Murray S. Kucherawy wrote: COMMENT: The DNS is case-insensitive so this is a minor point, but would there be any benefit to specifying that the registry only records the all-lowercase version of an underscore name? Mumble. The registry entries, of course, are not DNS entities. So aspects of registry use might care, such as for comparisons. And since uniqueness is the whole goal, forcing entries to use a single case simplifies comparison. I'm inclined to do as Murray suggests. COMMENT: The text specifically calls for a stable reference. Do we have guidance about what constitutes such a thing? I believe IANA has its own guidelines to that end; are they available to the Designated Expert? I'm inclined to let IANA raise this if they see and issue and then let them drive the resolution of this point. Section 6: COMMENT: I have doubts that SECDIR would accept this one-sentence comment. I suggest saying something more specific, like: "This document establishes a registry, and encourages a slight reorganization of attributes stored in the DNS. It establishes no new security issues." The first clause is redundant and makes sense to have here only either if the readers of this section haven't read the rest of the document, or if the clause is useful to what follows. I believe neither applies here. I don't understand the 'encourages' statement but suspect I don't agree. That leaves language that is equivalent to the existing language... Section 6.1: COMMENT: This seems to me to be content that belongs in its own section outside of Section 6 since it doesn't seem to me to be a security issue, but it's worth saying. Maybe give it its own section between what's now Sections 3 and 4? Well, I agree it's awkward where it is, but gosh. An entire major section? For such a small and explanatory -- rather than specification/normative bit of text? Mumble. If no one minds, I would rather make it Section 1.4, just after the sub-section tht describes the construct. I think it actually works well there. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf
On 7/13/2018 9:16 AM, Tim Wicinski wrote: which means either we're both correct or we're both incorrect. for the latter possibility, not just both incorrect, but both incorrect in the same way... that's probably a variant of 'great minds think alike'... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf
On 7/12/2018 8:29 PM, John Levine wrote: The text in the new section on wildcards is mildly fractured, looks like a cut and paste error. I don't see it, unless you are referring to the removed underscore characters, which was intentional. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf
Folks, Since WG LC closed for the two attrleaf drafts yesterday, I've generated revised versions based on the LC feedback. I'll submit them as I-Ds when the window opens back up on Monday. In the interim, here is a link to the revised drafts and diffs between them and their predecessor drafts: https://www.dropbox.com/sh/iex14dfnieq5dfq/AAAsedMLheGdBh6qbwm7tpcAa?dl=0 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf
On 7/12/2018 3:09 AM, Dick Franks wrote: So there's now text in attrleaf that explains about hierarchy, top, highest, and the original presentation convention of right, but noting that other presentations are possible. IMO unnecessary. This will inevitably either overlap or conflict with the draft RFC7719-bis DNS terminology document. I don't understand what 'overlap' you think will exist, but am pretty sure I don't agree. Better to use already battle-hardened terminology throughout and add RFC7719-bis citation. If it is that battle-hardened for this type of use, then there is no doubt a single term in the draft that has already gained widespread use. Which one is it? It then declares the term 'global' as referring to the node name of interest and only uses that term in the rest of the document. "global" does not tick the right box for me. And yet that's the distinguishing name of the attrleaf table in the drafts and has been for quite a long time. There haven't been any objections to that term until now. Perhaps the underscore-prefixed label (sequence? / tree?) needs to be described as subordinate to (or rooted at?) a "principal name". Perhaps you have some usability data that demonstrates pragmatic superiority of a particular choice over 'global' for /this/ kind of use and can point to the entry in the bis document that already defines it? Note that the choice echoes the use of 'global dns' that /is/ listed, to get at the semantics of the 'reach' for the highest-level underscore name. (Well, there are a couple of places where 'highest' was needed as clarification.) Stephane: "more/most general" Except that that has no obvious semantic merit, whereas 'highest' is directly motivated by referring to position in a hierarchy. otherwise: "closer/closest to the root" Why? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf
On 7/6/2018 8:22 AM, Stephane Bortzmeyer wrote: Editorial: I would prefer all occurrences of "right-most" to be replaced by "most general", to emphasize that it is not the position which matters, it is the closeness to the root. Editorial: 'that is they are the "top" of a DNS branch, under a "parent" domain name.' I assume that "top" is used instead of "apex" because the sentence does not always refer to the top of a zone? So, this turned into a niggling 'thing' for me and produced a collection of small changes. The basic model now is to introduce the issue early in the document and dispatch it once, and then use a single term for the rest of the document, without all the distractingly redundant clarifications. So there's now text in attrleaf that explains about hierarchy, top, highest, and the original presentation convention of right, but noting that other presentations are possible. It then declares the term 'global' as referring to the node name of interest and only uses that term in the rest of the document. (Well, there are a couple of places where 'highest' was needed as clarification.) The -fix document doesn't stand alone, so it merely continues the convention and does not re-explain it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf-fix
On 6/28/2018 12:02 PM, Paul Hoffman wrote: On 28 Jun 2018, at 7:19, Dave Crocker wrote: On 6/27/2018 3:01 PM, Paul Hoffman wrote: Due to its nature, the document is a bit difficult to read, but I don't have any suggestion about how to make it better. Could you at least provide some description of what it is that you find difficult? It feels like it loops into itself, where 3.1 and 3.2 sound like, but are different than, 2.2 and 2.3. I've stared it, and I don't see a way to make it better without making 2.2 and 2.3 more convoluted. It's not worth worrying about more unless someone else comes up with a simplification that is actually simpler. Hmmm. I did find some small-but-irritating disparities in parallel texts that should have been identical other than in naming the RR or other actual differences. But I suspect you are reacting to something else. Section 2 is about the specific, instance documents while Section 3 is about the 'meta' documents. These two sections need to have some similarities quite important differences, I think. Anyhow, I'm not seeing any significant changes more any obvious need for them, absent something figuring out the deeper issue you are reacting to. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf
On 7/9/2018 2:35 PM, Dick Franks wrote: On 9 July 2018 at 19:48, Dave Crocker <mailto:d...@dcrocker.net>> wrote: >8 Does this cause anyone intolerable heart-burn? If it does, please at least explain but preferably offer something better. I do not suffer from intolerable heart-burn but happy to offer: If a public specification calls for the use of an underscore-prefixed domain name, the underscored name closest to the root MUST be entered into this registry. Thanks. I've added some tweakage to your text: If a public specification calls for use of an _underscore-prefixed domain node name, the 'global' underscored name -- the name that is closest to the DNS root -- MUST be entered into this registry. Historically, this is the right-most name that is begins with an underscore. > (Editorial: The word underscore does not itself need to be > underscore_prefixed) It's there as clarification/reminder, in case the reader isn't sure what character is meant. But I'll re-calibrate its use and take out extra ones... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf
On 7/9/2018 2:09 PM, John Levine wrote: Since it'll always be on the right for people reading this document in English, I'd rather leave it alone. Except that a) RFCs get translated, and b) people implement RFCs all over the world, including places that display rtl. (cf, 'robustness'.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf
On 7/6/2018 8:22 AM, Stephane Bortzmeyer wrote: On Mon, Jun 25, 2018 at 12:27:17PM +0200, Benno Overeinder wrote a message of 27 lines which said: This starts a Working Group Last Call for draft-ietf-dnsop-attrleaf I've read -10 and it seems OK. It solves a real issue, and does it properly. Editorial: I would prefer all occurrences of "right-most" to be replaced by "most general", to emphasize that it is not the position which matters, it is the closeness to the root. G'day. Given the reality of arguably-legitimate left-to-right domain name hierarchy presentation in some contexts, and given a desire to have specification text that is both correct and robust, I'm going to suggest a bit more verbosity in the attrleaf document, along the lines of... from: If a public specification calls for use of an _underscore-prefixed domain node name, the 'global' (right-most) _underscored name MUST be entered into this registry. to: If a public specification calls for use of an _underscore-prefixed domain node name, the 'global' (highest level, and typically right-most) _underscored name MUST be entered into this registry. Does this cause anyone intolerable heart-burn? If it does, please at least explain but preferably offer something better. Thanks. d/ -- -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf
On 7/6/2018 9:35 AM, John Levine wrote: Translator's note: change this to "left most" when translated to Arabic or Hebrew. in rtl contexts, domain names are shown with the root at the left??? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf
On 7/6/2018 8:39 AM, Dave Crocker wrote: Editorial: 'that is they are the "top" of a DNS branch, under a "parent" domain name.' I assume that "top" is used instead of "apex" because the sentence does not always refer to the top of a zone? 'zone' is almost certainly not the term to apply here. While it encompasses a sub-tree, its boundary is not explicit in a domain name. The DNS is a hierarchy. I would have though 'top of a sub-branch' was therefore clear, concise and accurate. Again, if there is other phrasing that is more established, we should use it. But I'm not used to seeing 'apex', though it's certainly a more erudite choice... I went back and looked at the terminology draft that is in last call. I assume that is where 'apex' came from. However I'll claim that none of the language in that section of the document actually covers what is being described here, because this isn't about 'zones'... FWIW, my sense is that the term zone has actually become quite ambiguous... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf
Stephane, thanks for the comments. Inline... On 7/6/2018 8:22 AM, Stephane Bortzmeyer wrote: On Mon, Jun 25, 2018 at 12:27:17PM +0200, Benno Overeinder wrote a message of 27 lines which said: This starts a Working Group Last Call for draft-ietf-dnsop-attrleaf I've read -10 and it seems OK. It solves a real issue, and does it properly. Editorial: I would prefer all occurrences of "right-most" to be replaced by "most general", to emphasize that it is not the position which matters, it is the closeness to the root. So let's start by making sure we're seeking the same goal: reader comprehension. While I can imagine there is phrasing that is better than right-most, to achieve that comprehension, I believe 'most general' isn't it. My impression has been that 'right-most' is the most common phrasing people have used over the years. Editorial: 'that is they are the "top" of a DNS branch, under a "parent" domain name.' I assume that "top" is used instead of "apex" because the sentence does not always refer to the top of a zone? 'zone' is almost certainly not the term to apply here. While it encompasses a sub-tree, its boundary is not explicit in a domain name. The DNS is a hierarchy. I would have though 'top of a sub-branch' was therefore clear, concise and accurate. Again, if there is other phrasing that is more established, we should use it. But I'm not used to seeing 'apex', though it's certainly a more erudite choice... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf-fix
On 6/27/2018 3:01 PM, Paul Hoffman wrote: Due to its nature, the document is a bit difficult to read, but I don't have any suggestion about how to make it better. Could you at least provide some description of what it is that you find difficult? The only problem I have with the document is that there are lots of informational references that are not referred to in the body of the text; they are not even listed in the Updates list at the top of the document. This should either be explained clearly in the body of the document or removed. Assuming my xml processor produces the same list of not-used references as yours: most indeed needed to be added to the Updates list and have been. A few were carry-overs from the base document and indeed are unused here; they've been drops. Thanks for the audit. FWIW, I'd considered replicating the Updates list in the body of the document, solely to get rid of the 'unused' list during processing, but decided that merely invites divergent copies... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf
On 6/25/2018 12:22 PM, John R Levine wrote: I'm feeling lazy. Care to suggest text to add and its location in -attrleaf, John? See below. thanks! absent objections, I'll add it to the post-WGLC version. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf
On 6/25/2018 11:13 AM, Ray Bellis wrote: On 25/06/2018 22:08, John Levine wrote: One minor point in attrleaf, is whether to mention the poor interactions between _names and wildcards. One issue is that _blah.*.example doesn't work, the other is that *.example will match underscored names which can be surprising if it has RRs of a type that might be underscored, notably TXT. Isn't the issue with wildcards already well addressed in the IAB document on extending the DNS ? (RFC 5507). Yes, but... This is certainly a universal issue with _names and it's one that seems not to be obvious to many folk. So while the mathematics of purity should be satisfied that the issue is document somewhere, the probabilities of reader psychology might encourage some judicious redundancy. And RFCs nicely permit pedagogy along with specification. I'm feeling lazy. Care to suggest text to add and its location in -attrleaf, John? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-09.txt
On 5/23/2018 4:11 PM, John Levine wrote: I took a look at -attrleaf and -attrleaf-fix and the both look good to me. The language about parent names is correct but a little confusing. If I can figure out a less confusing way to reword it I'll pass it along. Since it seems to be the only place with the string "parent name", I assume you mean: Scaling Benefits ... An increasingly-popular approach, with excellent scaling properties, places the RRset under a node having an underscore-based name, at a defined place in the DNS tree under the 'parent' name. This constrains the use of particular RR types associated with that parent name. How about: An increasingly-popular approach, with excellent scaling properties, places the RRset under a specially-name branch, which is in turn under the node name that would otherwise contain the RRset. The rules for naming that branch define the context for interpreting the RRset. That is, rather than: domain-name.example / RRset the arrangement is: _branch.domain-name.example / RRset d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-09.txt
Folks, Apologies for posting a revision this fast, but since I've suggested Last Call, I wanted to get this delta into the mix: Just had folk working on a spec ask what text they should use in their document, to register entries in the table. The section I've added to the base Attrleaf draft is drawn from the template used in the 'fix' document. d/ Forwarded Message Subject: New Version Notification for draft-ietf-dnsop-attrleaf-09.txt Date: Tue, 22 May 2018 12:05:11 -0700 From: internet-dra...@ietf.org To: Dave Crocker A new version of I-D, draft-ietf-dnsop-attrleaf-09.txt has been successfully submitted by Dave Crocker and posted to the IETF repository. Name: draft-ietf-dnsop-attrleaf Revision: 09 Title: DNS Scoped Data Through '_Underscore' Naming of Attribute Leaves Document date: 2018-05-22 Group: dnsop Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-ietf-dnsop-attrleaf-09.txt Status: https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/ Htmlized: https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-09 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-09 -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-fix-01.txt
Sorry. Meant to include the links from the announcement, especially for diffs. d/ Forwarded Message Subject: New Version Notification for draft-ietf-dnsop-attrleaf-fix-01.txt Date: Tue, 22 May 2018 10:14:34 -0700 From: internet-dra...@ietf.org To: Dave Crocker A new version of I-D, draft-ietf-dnsop-attrleaf-fix-01.txt has been successfully submitted by Dave Crocker and posted to the IETF repository. Name: draft-ietf-dnsop-attrleaf-fix Revision: 01 Title: DNS Attrleaf Changes: Fixing Specifications with _Underscored Node Name Use Document date: 2018-05-22 Group: dnsop Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-ietf-dnsop-attrleaf-fix-01.txt Status: https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf-fix/ Htmlized: https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-fix-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-fix Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-fix-01 -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: I-D Action: draft-ietf-dnsop-attrleaf-fix-01.txt
Ditto. Ready for Last Call? d/ Forwarded Message Subject: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-fix-01.txt Date: Tue, 22 May 2018 10:14:34 -0700 From: internet-dra...@ietf.org To: i-d-annou...@ietf.org CC: dnsop@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : DNS Attrleaf Changes: Fixing Specifications with _Underscored Node Name Use Author : Dave Crocker Filename: draft-ietf-dnsop-attrleaf-fix-01.txt Pages : 13 Date: 2018-05-22 -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-08.txt
Ready for Last Call? d/ Forwarded Message Subject: New Version Notification for draft-ietf-dnsop-attrleaf-08.txt Date: Tue, 22 May 2018 10:12:06 -0700 From: internet-dra...@ietf.org To: Dave Crocker A new version of I-D, draft-ietf-dnsop-attrleaf-08.txt has been successfully submitted by Dave Crocker and posted to the IETF repository. Name: draft-ietf-dnsop-attrleaf Revision: 08 Title: DNS Scoped Data Through '_Underscore' Naming of Attribute Leaves Document date: 2018-05-22 Group: dnsop Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-ietf-dnsop-attrleaf-08.txt Status: https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/ Htmlized: https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-08 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-08 -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-fix-00.txt
On 5/12/2018 1:01 PM, John R Levine wrote: The best I can guess is that there is an underlying assumption that normative language only applies to formally published specifications, but there's nothing in the current draft language to support that. No, it's that standards are about interoperating with people you don't know. That was the point of the two-implementation rule. This particular situation is unusually squishy because we have a list of protocol names and a list of enumservice types that aren't in the registry but in practice it'd work fine if someone used one of them because none of the names currently conflict. Avoiding naming collisions is a form of interoperating. Perhaps unfortunately, we have extensive experience that failing to coordinate across independent efforts -- ie, failing to have a common registry -- does not cause immediate failure. My current thought is that the draft's language should direct a MUST for 'published' specifications. This would implicitly leave private, developmental efforts free to experiment without registration. Note that SHOULD really is the same as MUST, except it allows for a 'unless you really know what you are doing'. That, it seems to me, is exactly right, for this issue. Except that in reality people violate MUST all the time, often for good reasons. This is why I don't understand the difference any more. Oh? They do? And it isn't because the MUST should have been a SHOULD? And it isn't because those good reasons aren't really all that good? And it isn't because... You offer your summary assessment without any detail, but apparently intend it to negate the clearly-defined semantic distinction and usage intent behind the two normative choices. It's entirely possible that some specification writers or working groups have been sloppy. And there are are other possibilities. None of which justify ignoring the meaning and purpose of the normative choices. I suggest, instead, that the working group should consider what the force and import of a MUST would be, versus the force and import of a SHOULD, and that it do that on the assumption that the terms mean what they are defined to mean and should be used as they are intended to be used. In section 1 you might want to add a sentence or two pointing out that every rrtype has its own _name namespace, something that took a lot of us quite a while to figure out. I'll urge not doing that. Yes, it's a mathematical truth, but it's one that I believe some/many other folk will find confusing in practical terms. (I know I certainly did...) Then it should be more than a sentence or two, long enough to explain it. It needs to be clear people who might register future names that if _foo on SRV and _foo on TXT mean different things, that's not a problem. OK, but absent your suggesting specific text, I don't know what will satisfy. For URIs, I'd add all of the existing enumservice type names to the draft-ietf-dnsop-attrleaf initial name list in section 3.1, and in I'll guess that you mean the existing entries in the 'type' column of: https://www.iana.org/assignments/enum-services/enum-services.xhtml which appears to be: acct email ... which seems quite a lot of pre-loading, for an RR that has almost no use, so far. I would instead suggest pre-loading only those 'type' values we know to be already in use and press for additional entries when they will get used. This is what we've done for Proto, so why not the same approach for enumservice? I suppose that's OK. Do we have any idea of what the handful of URIs in the wild actually use? I don't. Does anybody in the working group know the details of current URI RRset usage? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-fix-00.txt
On 5/11/2018 7:41 PM, John Levine wrote: I'd change all of the SHOULD to MUST, as in you have to do this if you want to interoperate. The working group should consider the choice of normative level, but where I landed is that a MUST is not needed and actually could be counterproductive. Having an entry in the registry probably does facilitate interoperability at scale, but it isn't (always) required for it. What it /is/ required for is avoiding naming collisions. Consider the long history of email header fields that weren't registered but which interoperated quite nicely... > (You don't have to > do it if you have a private agreement, but private agreements are out > of the scope of standards.) I don't see the basis for saying that private agreements are out of scope, on the matter of registration. The best I can guess is that there is an underlying assumption that normative language only applies to formally published specifications, but there's nothing in the current draft language to support that. Note that SHOULD really is the same as MUST, except it allows for a 'unless you really know what you are doing'. That, it seems to me, is exactly right, for this issue. In section 1 you might want to add a sentence or two pointing out that every rrtype has its own _name namespace, something that took a lot of us quite a while to figure out. I'll urge not doing that. Yes, it's a mathematical truth, but it's one that I believe some/many other folk will find confusing in practical terms. (I know I certainly did...) In section 3.1 on SRV it says about Proto "any name defined by Assigned Numbers or locally may be used (as for Service)." Urrgh. I'd say that any protocol whose name is in the attrleaf registry is You appear to have quote the portion introduced with: "The text of that specification is hereby updated from:" which is taken from the existing SRV specification, and appear to have missed the 'from', rather than focusing on the next set of text, introduced with: "The updated text is:" which does not contain the text you find problematic. For URIs, I'd add all of the existing enumservice type names to the draft-ietf-dnsop-attrleaf initial name list in section 3.1, and in I'll guess that you mean the existing entries in the 'type' column of: https://www.iana.org/assignments/enum-services/enum-services.xhtml which appears to be: acct email ems fax ft h323 iax ical-access ical-sched ifax im mms pres pstn pstn sip sms unifmsg vcard videomsg voice voicemsg vpim web xmpp which seems quite a lot of pre-loading, for an RR that has almost no use, so far. I would instead suggest pre-loading only those 'type' values we know to be already in use and press for additional entries when they will get used. This is what we've done for Proto, so why not the same approach for enumservice? this draft add a note that any new enumservice types added MUST be added to this registry if URIs can refer to them. There's currently 24 type names. It happens that none of them collide with other top level names but since they only apply to URI it wouldn't matter if they did. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-fix-00.txt
On 5/11/2018 3:28 PM, Warren Kumari wrote: I'm going to be rude and not answer any of the below questions -- instead, I'm going to mention "SMTP MTA Strict Transport Security (MTA-STS) draft-ietf-uta-mta-sts" (which completed IETF LC, etc a while back). This document uses the label _mta_sts: The MTA-STS TXT record is a TXT record with the name "_mta-sts" at the Policy Domain. For the domain "example.com <http://example.com>", this record would be "_mta-sts.example.com <http://mta-sts.example.com>". I'm mentioning it so that, when we have a registry, just like _acme-challenge is mentioned in draft-ietf-dnsop-attrleaf/, we can add it. Warren, As rudenesses go, that was entirely too constructive. Try harder. While it doesn't have an RFC number yet, we are far enough from publication for our document to make me think it will have a number by then. As such, it merely needs to get added to the 'updates' set. And as such, it means that you responded to the third question. So yeah, try harder. Oh, and thanks for the quick attention! d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-fix-00.txt
Folks, G'day. The latest wg's agreed approach for the Attrleaf specification is to have a clean-sheet document that does /not/ reflect the problematic history, with a companion specification that does. That is, the first document is to specify the registry as if there were no history of independent _underscored names (other than creating registry entries for those existing node names.) The current draft-ietf-dnsop-attrleaf specification provides the clean-sheet approach. I think it is within epsilon of doing what we've agreed it should do. That leaves the messiness of dealing with the many documents that created that _underscored history and the requisite cleanup of it, for a companion document. The document just announced (attrleaf-fix, cited below) serves that purpose. I tried to make the document complete in terms of structure AND detail. While I think the structural approach of the draft is reasonable, I don't believe for all the detail that's needed is there. For working group review, I suggest folk consider the draft in terms of 3, basic concerns: Clarity: Does the draft adequately explain its purpose and adequately explain its approach for satisfying that purpose (separate from its whether it achieves that goal well enough?) Efficacy: Does the draft's approach seem sufficient to it's task? Completness: Does the draft have all of the necessary detail and is all that detail correct? I'm quite sure the document is /not/ complete and strongly encourage careful commentary on-list or off, so we can remedy this. But please also consider the first two points, especially for a reader who does not already have deep background in this topic. Thanks. d/ Forwarded Message A new version of I-D, draft-ietf-dnsop-attrleaf-fix-00.txt has been successfully submitted by Dave Crocker and posted to the IETF repository. Name: draft-ietf-dnsop-attrleaf-fix Revision: 00 Title: DNS Attrleaf Changes: Fixing Specifications with _Underscored Node Name Use Document date: 2018-05-03 Group: dnsop Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-ietf-dnsop-attrleaf-fix-00.txt Status: https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf-fix/ Htmlized: https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-fix-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-fix Abstract: Original uses of an _underscore character as a domain node name prefix, which creates a space for constrained interpretation of resource records, were specified without the benefit of an IANA registry. This produced an entirely uncoordinated set of name- creation activities, all drawing from the same namespace. A registry now has been defined. However the existing specifications that use _underscore naming need to be modified, to be in line with the new registry. This document specifies those changes. The changes preserve existing software and operational practice, while adapting the specifications for those practices to the newer _underscore registry model. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] URI text for attrleaf?
On 3/31/2018 9:08 AM, John R. Levine wrote: On Fri, 30 Mar 2018, Dave Crocker wrote: but I can't figure exactly how, nor how to resolve drawing the global value from two independent namespaces... But this ignores handling names from enumservice. Thoughts? Suggestion? Text? Add URI entries for all of the enumservices types, _acct, _email, _ems, _fax, _ft, _h323, _iax, _ical-access, _ical-sched, _ifax, _im, _mms, _pres, _pstn, _sip, _sms, _unifmsg, _vcard, _videomsg, _voice, _voicemsg, _vpim, _web, _xmpp that point to RFC 7553. This has the hypothetical possibility that someone might define a transport with a name the same as an enumservice type, but I think we're into "don't do that" territory. That's simple and reasonable, but is it sufficient? Would some other folk comment, just to establish a wg tone on doing this? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] URI text for attrleaf? (was: Re: New Version Notification for draft-ietf-dnsop-attrleaf-06.txt)
Folks, With the latest round of tweaks, I think the next version of the draft will be essentially complete. Except for needing to cover URI RRsets (RFC7553). Unfortunately I'm stumped and am not sure what text to include to handle it. Help! The 'global' (right-most) label appears to be permitted from two different sources, one is the same as for SRV (_proto) but the other is from based on an "ENUM Service Parameter", although I can't find am explicit definition of what that means. (Nor of "ENUMService Parameter".) I assume it is meant to draw from https://www.iana.org/assignments/enum-services/enum-services.xhtml#enum-services-1 but I can't figure exactly how, nor how to resolve drawing the global value from two independent namespaces... The relevant RFC7553 text is: 4.1. Owner Name, Class, and Type The URI owner name is subject to special conventions. Just like the SRV RR [RFC2782], the URI RR has service information encoded in its owner name. In order to encode the service for a specific owner name, one uses service parameters. Valid service parameters are those registered by IANA in the "Service Name and Transport Protocol Port Number Registry" [RFC6335] or as "Enumservice Registrations [RFC6117]. The Enumservice Registration parameters are reversed (i.e., subtype(s) before type), prepended with an underscore (_), and prepended to the owner name in separate labels. The underscore is prepended to the service parameters to avoid collisions with DNS labels that occur in nature, and the order is reversed to make it possible to do delegations, if needed, to different zones (and therefore providers of DNS). The easy part of this is to add entries to the global attrleaf trable for: URI _dccp URI _sctp URI _tcp URI _udp But this ignores handling names from enumservice. Thoughts? Suggestion? Text? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [art] Another look - draft-ietf-dnsop-attrleaf-05.txt
On 3/29/2018 3:38 PM, Adam Roach wrote: I still don't fully understand the nature of the objections I cite above or the assertions that having separate tables for different RRTYPEs is somehow broken. Based on my (admittedly lay) understanding of how DNS is used by other protocols, I agree with your proposal that having distinct tables for each RRTYPE makes far more sense than the current structure. 1. Another round of thanks. On re-starting the effort, I'd missed that exchange. I think adding "Scope is meant as a static property, not one dependent on the nature of the query. It is an artifact of the DNS name." from it, to the Intro will help a bit. 2. I think the latest round of discussion and change arguably implements your view, albeit within a single actual registry. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-06.txt
On 3/29/2018 10:30 AM, Paul Vixie wrote: since the _ was chosen as nonconflicting, and since you desire to explain what it is we aren't conflicting with, and since the RFC 1035 language is both non-normative and archaic by inspection, i really think that 952 is the correct, and only correct, reference to use. Thanks for the detailed explication. I think it's odd to have a DNS naming-related discussion that does not cite either of the seminal standards documents for domain naming, but I suppose there's isn't much downside at this place in the document, to cite only RFC 952. as a side node, RFC 952 permits host names of only 24 characters or less, including those which have interior periods for RFC 921 purposes. therefore, a protocol lawyer could say that any name longer than 24 characters, or beginning with a number, was by definition non-conflicting with RFC 952, and needs no underscore to achieve same. i do not harbor this view, and i believe that the LEXICAL GRAMMAR section is more definitional than the ASSUMPTIONS section of RFC 952. To me, that's an example of the problem with citing only that document: It is not definitive on 'host name'. That RFC 1035 isn't, really, either was my reason for wanting to cite both. But anyhow, the next version will have only 952. Trying to eliminate the issue entirely, is this sufficient: Some resource record types are used in a fashion that can create scaling problems, if an entire RRset associated with a domain name is aggregated in the leaf node for that name. An increasingly-popular approach, with excellent scaling properties, places the RR under a node having an underscore-based name, at a defined place in the DNS tree under the 'parent' name. This constrains the use of particular RR types associated with that parent name. A direct lookup to the subordinate leaf node produces only the desired record types, at no greater cost than a typical DNS lookup. The definition of a underscore global registry, provided in this specification, primarily attends to the top-most names used for coping an RR type; that is the _underscore "global" names. it's almost 100% of the way there. but, you should say "places the RRset" oops. quite correct. in: 2. DNS Underscore Scoped Entry Registries Function ... /name space/name space, just as every RR type owns a distinct, subordinate name space./ An RR type owns a name space? I don't understand what that means or how it is correct. While I think I see a computer science basis for saying that an RR type has a namespace, I'm continuing to find the point more confusing than helpful, and fear that other readers will, too. At the least, can you point me to official documents that explain that view? I've looked around a bit an haven't found such a specification or discussion. it only contains a namespace for the purposes of your underscore registry. no use of _TCP by any other RR type will conflict with the use of _TCP by SRV, for example. thus, each RR type effectively has its own registry, whose names need only be unique within that registry. you may prefer to call it a dictionary rather than a namespace in order to avoid confusion around what other DNS RFC's call a "namespace". Oh. Alas, I'm still not seeing how this is helpful pedagogy for the average reader. Let's suspend this until the next version and see how the doc sits with folks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt
On 3/29/2018 1:45 PM, Warren Kumari wrote: I don't want to get into if this is the*right* behavior or not, but it seems like worth mentioning in the draft as it has much background already... I can find nothing which states that A / cannot be associated with underscore names, but they sure don't seem to work in practice. The current version is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/ Please suggest specific text to use and where to put it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-06.txt
Paul, On 3/29/2018 9:31 AM, Paul Vixie wrote: in: 1.1. _Underscore Scoping ... s/[RFC1035]/[RFC952]/ (first occurrence) hmmm. I suggest listing both, since RFC1035 both cites the precedence of RFC952 as well as supplying an (apparently redundant) formal syntax specification for host name. the reference to 952 in 1035 is only in the bibliography, and does not specifically discuss its relationship to A RR owner names or to MX RR targets. if you can show me the part of 1035 you think is relevant to the definition of a host name, i'd like to see it. The text in RFC 1035 I have in mind is: > 2.3.1. Preferred name syntax ... When creating a new host name, the old rules for HOSTS.TXT should be followed. This avoids problems when old software is converted to use domain names. The following syntax will result in fewer problems with many applications that use domain names (e.g., mail, TELNET). ::= | " " ::= | "." ::= [ [ ] ] So, no, it doesn't explicitly cite the RFC number, but I read it as citing the substance. in: 1.2. Scaling Benefits for TXT, SRV, and URI Resource Records s/SRV,//; S/"SRV",// OR s/Some resource records are generic and support a variety of uses.//; s/Their use can scale poorly.*different uses\.//; s/increasingly-popular//; s/approach,/approach/ Sorry, not understanding the issue(s). Please clarify. Here's my guess at the concern: SRV is viewed as not generic and/or doesn't have scaling problems? ... it's not increasingly popular, it doesn't scale poorly, and it's not generic. so you can either remove those descriptions of SRV, or you can remove SRV as the object of your description, or you can finesse it. Trying to eliminate the issue entirely, is this sufficient: Some resource record types are used in a fashion that can create scaling problems, if an entire RRset associated with a domain name is aggregated in the leaf node for that name. An increasingly-popular approach, with excellent scaling properties, places the RR under a node having an underscore-based name, at a defined place in the DNS tree under the 'parent' name. This constrains the use of particular RR types associated with that parent name. A direct lookup to the subordinate leaf node produces only the desired record types, at no greater cost than a typical DNS lookup. The definition of a underscore global registry, provided in this specification, primarily attends to the top-most names used for coping an RR type; that is the _underscore "global" names. in: 2. DNS Underscore Scoped Entry Registries Function ... /name space/name space, just as every RR type owns a distinct, subordinate name space./ An RR type owns a name space? I don't understand what that means or how it is correct. While I think I see a computer science basis for saying that an RR type has a namespace, I'm continuing to find the point more confusing than helpful, and fear that other readers will, too. At the least, can you point me to official documents that explain that view? I've looked around a bit an haven't found such a specification or discussion. Note, for example, that RFC 1034 says: > 2.4. Elements of the DNS ... The DOMAIN NAME SPACE and RESOURCE RECORDS, which are specifications for a tree structured name space and data associated with the names. Conceptually, each node and leaf of the domain name space tree names a set of information, and query operations are attempts to extract specific types of information from a particular set. which is not language that lends itself towards saying that an RR type has its own namespace. I don't see anything in RFC 1035 that works for that view, either. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-06.txt
On 3/28/2018 11:41 AM, Paul Vixie wrote: dave, HEREIS. --paul Cool. Thanks! (Sorry for the sloppy vocabulary usage. By way of an empathy signal cf, common use of 'header' in email when it should be 'header field'...) I've gone through the entire document and reviewed all occurrences RR and resource record strings. The results don't exactly the match the set of changes you specify, but did produce quite a few changes. The RFC 2181 definition resource record set is a set of records of the /same/ type. In some cases, that isn't what's meant, so I didn't change the text. In some cases, the text's intent is to to cover RRs of /different/ types populating the same leaf. As I read the definition, that's not covered by RRset. Inline questions/comments/concerns... in: 1.1. _Underscore Scoping ... s/specific resource records/specific resource record sets/ Current text: "That scope is a leaf node, within which the uses of specific resource records can be formally defined and constrained." I often find that there is wording danger in using plurals, that can be avoided with the singular. I think the issue here can be simplified by changing the text to: "That scope is a leaf node, within which the uses of a specific resource record type can be formally defined and constrained." s/[RFC1035]/[RFC952]/ (first occurrence) hmmm. I suggest listing both, since RFC1035 both cites the precedence of RFC952 as well as supplying an (apparently redundant) formal syntax specification for host name. in: 1.2. Scaling Benefits for TXT, SRV, and URI Resource Records s/SRV,//; S/"SRV",// OR s/Some resource records are generic and support a variety of uses.//; s/Their use can scale poorly.*different uses\.//; s/increasingly-popular//; s/approach,/approach/ Sorry, not understanding the issue(s). Please clarify. Here's my guess at the concern: SRV is viewed as not generic and/or doesn't have scaling problems? There is a type of variability to the use of some RR types that effectively means they have variation in their role, not just their payload. TXT is the extreme example of this. SRV is more interesting, because it was designed for that variability. Glad to use a term other than generic, but I don't have an obvious alternative that suits. The variability of such types can make it problematic to aggregate all occurrences of them into the same node, even though they are associated with that node. The underscore naming approach separates these subsets. Again, SRV is interesting because it was designed with that naming as part of its original design. However the fact that it was designed with the solution from the start doesn't relieve it of needing that solution. The text, here, is attempting to characterize a motivating issue, namely a scaling challenge that occurs due to the variability of use for some RR types. s/RR/RRset/ (note, leave "RR"s alone) The substitution command seems to be at odds with the comment. Please explain. in: 2. DNS Underscore Scoped Entry Registries Function ... /name space/name space, just as every RR type owns a distinct, subordinate name space./ An RR type owns a name space? I don't understand what that means or how it is correct. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] End-to-end _underscore arguments (was: Re: [art] Another look - draft-ietf-dnsop-attrleaf-05.txt)
ve punted on the details for the URI RR, given some complexities in RFC 6117. If anyone wants to suggest specific text for this, it would be greatly appreciated. 5. There is still a second document needed, to fix the various documents that specify global underscore names, so that these documents are updated to cite the registry. Once things settle down for this main draft, I'll work on that one. Thoughts? d/ ps. Another round of hearty thanks to Ray Bellis for his offlist interactions with me on this, though of course he gets none of the blame for my getting any of this wrong... -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Additional uses of underscore labels
On 3/28/2018 5:49 AM, Martin Hoffmann wrote: draft-ietf-acme-acme defines _acme-challenge for TXT records. Thanks. Added to the next version. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [art] Another look - draft-ietf-dnsop-attrleaf-05.txt
On 3/26/2018 8:18 AM, Martin Hoffmann wrote: Which also reminds me: The DANE RRtypes, ie., TLSA, SMIMEA, and OPENPGPKEY all use underscore labels and are currently missing from the initial table in section 3.1. Added TLSA to the next version of the draft. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] namespace and substring reservations (was Re: Another look - draft-ietf-dnsop-attrleaf-05.txt)
On 3/26/2018 12:07 AM, Paul Vixie wrote: John C Klensin wrote: it is not clear to me that the set of labels starting with "_" constitute a namespace, any more than the set of labels starting with "xn--" do. It is just a naming convention that identifies the labels as keywords with defined meaning. 1. This seems to require a very precise definition of the term namespace, but doesn't cite it. Here's mine -- although it's different from Wikipedia's: An integrated (probably contiguous) range of values from which names can be chosen. And elaborated: A set of rules for assigning names out of a common space of values. 2. If "_" at the beginning of a DNS label does not define a namespace in the current DNS, then it can't be subject to any distinct set of rules. In actual practice, the use of "_" as the first character is now fully entrenched. Debating what to call the space it controls doesn't change established practice. 3. I don't understand how xn-- can be any less reserved for exclusive use. That is, I believe the convention of using xn-- has reserved that string for only that use and that the document choosing that string has formally made that restriction. The goal of the current draft is to bring the space of names starting with underscore under unified control. With the publication of a draft like this, the use of underscore as the first character makes its use reserved. All of this has to do with name /assignment/, but makes no changes on name /resolution/. Name resolution remains blissfully unaware of any rules about name assignment or 'meaning'. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] _openpgpkey & _smimecert (was: Re: [art] Another look - draft-ietf-dnsop-attrleaf-05.txt)
On 3/26/2018 8:56 AM, Martin Hoffmann wrote: RFC 7929 defines _openpgpkey for use with the OPENPGPKEY record type. RFC 8162 defines _smimecert for use with the SMIME record type. Confirming addition of these to the /global/ underscore registry table for the next version of the draft. Thanks! d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt
On 3/26/2018 9:14 AM, John C Klensin wrote: (1) The text in Section 1.1 says 'the DNS rules for a "host" (host name) are not allowed to use the underscore character... legal host names [RFC1035]' 1035 does not say that. Its section 2.3.1 is about what is preferred, not what is required (or "legal"). It says "should" Note that when that spec was written, we didn't have such precise and rigid vocabulary rules. But RFC 1123 should be cited, especially since it has more forceful language: "The syntax of a legal Internet host name". (RFC6055 seems to have missed the import of 'legal'.) and "preferred", but there is no requirement. As far as I know, there has never been a serious attempt to turn that preference into a requirement. Indeed, RFC 8121 says exactly the opposite Please cite the specific text in that RFC you are referencing. and, if there were a prohibition, RFC 6055 would have been largely unnecessary. Overall, it appears that your claim is that the underscore naming convention is predicated on an erroneous interpretation of 'hostname' restrictions. As such, the entire activity is broken. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [art] Another look - draft-ietf-dnsop-attrleaf-05.txt
On 3/26/2018 8:18 AM, Martin Hoffmann wrote: Which also reminds me: The DANE RRtypes, ie., TLSA, SMIMEA, and OPENPGPKEY all use underscore labels and are currently missing from the initial table in section 3.1. The table there is for the right-most underscore name, which RFC 6698 seems to constrain to choices that are already list. The left-most underscore name appears to use a rule that differs from the rule used by SRV, etc. As such, these are second-level names being drawn from the same namespace but without coordination. So it looks like there's a problem, but not with the proposed global registry (for now.) Yes? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [art] New Version Notification for draft-ietf-dnsop-attrleaf-03.txt
On 3/23/2018 11:02 AM, John Levine wrote: I see a message on dnsop from you proposing a bunch of things including "rationalizing" names, and comments from Andrew and Peter saying they like that approach. I am not finding any message from me with that word in it, so I've no idea what you are referring to. Better still, my guess is that you are reacting to one or more messages from me before the one I sent that said 'Level set'. Take a look, at the latest draft. If you have concerns with it, please point to specific text in it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Attrleaf table entry fields (was: Re: I-D Action: draft-ietf-dnsop-attrleaf-04.txt)
On 3/22/2018 2:41 PM, Ray Bellis wrote: - the table formatting is pretty poor, do we really need any more than just "NAME", "RR" and "REFERENCE"? The ID field just seems to be an alternate mnemonic for the (already unique) underscore label itself I've looked over the latest version of the table with the above in mind. Wrestled a bit, and finally landed on 'yes', but want to record the thoughts justifying removing fields: ID: the _Node Name field really does serve that purpose well enough Purpose: The text that was there for most of the entries was mechanically redundant with information in other fields for the entry. Control: I've added overall text in a bulleted list before the table, that handles the 'authority' issue for each entry. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-04.txt
On 3/22/2018 2:41 PM, Ray Bellis wrote: Dave, I think this is much improved :) A few nits: Each globally-registered underscore name owns a distinct, subordinate name space. except when it doesn't (i.e. the SRV transports all share the *same* subordinate name space). Well, ummm, I think this demonstrates the difference between theory and practice. In theoretical terms -- as far as the global registration scheme goes -- they /do/ have their own name spaces. In practical terms, they adhere to some additional conventions that choose to use the same subordinate one. I suppose some sort of language that notes this possibility -- since it's a popular choice -- is worth adding, to moderate the tone of independence in the current draft. - on that note, _sctp and _dccp are missing from the global table. ack. - the table formatting is pretty poor, do we really need any more than just "NAME", "RR" and "REFERENCE"? The ID field just seems to be an alternate mnemonic for the (already unique) underscore label itself I added control because the message header field registration work has it and it occurred to me it's worth marking. - the IANA considerations still refer to the now non-existent common second-level table darn. thought i'd expunged them all. the word 'second' appears to now be fully absent from the next version of the draft... Not a nit: - is there a reference for IANA "First Come First Served" rules, and should we perhaps also mandate "specification required" as a pre-condition for registration? We don't want that table filled with any old junk without a stable specification. What is the downside of leaving the requirement out? I'm a minimalist in terms of the role of a registry. To the extent possible, I think that it only has to do registration with accountability. There are cases where more stringent requirements make sense, but I don't see this as one of them: there not any danger I can see in a useless registration entry and there's lots of namespace. Thoughts? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Attrleaf _second-Level modifications (was: Re: Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-03.txt)
On 3/20/2018 9:31 AM, John R. Levine wrote: 2. SRV and URI These need more detailed text, very much in the s/old/new style. The current text in them does a use-by-reference of existing tables defined for other purposes. The Update text will, instead, specify a requirement for adding entries in the Global or Common Second-Level registries. The second level registry, though, is a problem, because it tries to redefine the naming rules for SRV records. RFC 2782 said that SRV second level names are from the services in Assiged Numbers STD 2. RFC 3400 abolished STD 2 in favor of an IANA registry. That registry, the Service Name and Transport Protocol Port Number Registry, was cleaned up by RFC 6335 which reiterates the fact that the service names in that registry are the services used to name SRV records. RFC 7335 states that URI records are named the same as SRV, and also says you can use enumservice _subtype._type. We need to change the description of the second level name registry to say that SRV and URI are special, they use names from Ports and Services at the second level and URI uses enumservice subtypes, and take out all of the SRV entries. What's left is the grabbag of second level names used for other stuff like NAPTR and _adsp._domainkey. Folks, Level set: * I think what hung me up was mostly missing the reference to 'second-level' while focusing too much on the presence of the word 'special'. * For any use of an underscore first-level name, that also uses a second-level name, the authority over that second-level belongs entirely and solely to that first-level name. ..._my-second._firsta.example and ..._my-second._firstb.example have no conflict. So here's what needs to be clearer in the main attrleaf document and the fixup document: All /first-level/ uses of underscore names MUST be registered in the single, /global/ registry, for in order to avoid collisions. For second-level names, any name assignment scheme can be used, as long as it prevents collisions /within the scope of its own first-level name/. In the case of SRV, for example, that means that for the core SRV template specification document: 1. The first-level, _Proto name assignment text has to be updated to use the new, Attrleaf global table. 2. The second-level _Service name assignment text can remain unchanged, per RFC 6335. Point #2 is actually not 'special' at all. I'd entirely missed that the very strong need to do the first-level fixup did not also require messing with the existing second-level. As for the proposed 'common, second-level' table... Given that this seems to reduce the Attrleaf 'common second-level' table to only _adsp, I think it best to remove that table entirely from the main attrleaf document, and instead have the separate fixup document contain some text specific to the DKIM document's domain naming scheme, to indicate how future second-level names should be assigned. Since ADSP is historic, specifying modification to it doesn't make sense to modify it. Thoughts? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [art] New Version Notification for draft-ietf-dnsop-attrleaf-03.txt
On 3/21/2018 12:08 PM, Alexey Melnikov wrote: Possibly related to this question: what is the relationship of this draft to RFC 6335? Can separate registries be 'related'? Anyhow, I think these aren't. Perhaps you could ask a more detailed question? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
