Re: [Gen-art] [Last-Call] [DNSOP] [Ext] Genart last call review of draft-ietf-dnsop-rfc8499bis-09
On Mon, Sep 18, 2023 at 8:48 PM Michael Richardson wrote: > > Michael Richardson wrote: > > definition which was objected to by multiple IESG members. > > > https://datatracker.ietf.org/doc/draft-ietf-acme-integrations/ballot/ > > (in RFC-editor Q, on missref) > > > So, if you didn't like that definition before, then probably you > should > > object to RFC8499bis keeping it. > > Ted's original review that lead to this: > > https://mailarchive.ietf.org/arch/msg/dnsdir/Ev83RjCbQcC64paenZXJawKxu9k/ Thanks for the pointer. If I'm understanding Ted's critique correctly, he is objecting to conflating the definition of a domain name with the tree structured DNS namespace, and using graph theoretic language to make it harder for readers to understand. (Ted please correct my interpretation if needed). I agree with that. I think we need to clearly separate the definition of a domain name with the 'domain name space'. A domain name is just a sequence of labels, and is a concept that exists independent of the tree structured namespace of the global DNS (or any private DNS namespace for that matter). For example query names may not actually correspond to anything existing in the DNS namespace, yet they are still valid domain names; owners of TSIG records are domain names that just identify a TSIG key agreed upon by their users, and typically have nothing to do with the actual domain name space. Other examples can be cited. rfc8499bis-09 has the basic definition correct: Domain name: An ordered list of one or more labels. It then seems to muddy the waters a bit in the sub paragraph by describing the domain name space, and relating domain names to it. It would be better to have a separate definition in the document for "Domain Name Space", quote the relevant text from 1034, and make it clear that although nodes in the domain name space tree correspond to domain names, domain names can also exist independent of the namespace. Shumon. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [DNSOP] [Last-Call] [Ext] Genart last call review of draft-ietf-dnsop-rfc8499bis-09
On Mon, Sep 18, 2023 at 9:34 AM Paul Wouters wrote: > On Sun, 17 Sep 2023, Salz, Rich wrote: > > [ speaking as individual only ] > > >>> On the other hand, spending a week or two repeating a cycle to get an > important term in the current document seems like a better solution. > > > >> If the WG agrees that this is an important term, sure. > > > > Well, if the IETF has consensus :) I'm raising the issue during this > last call that "round-robin" should be in the list of defined terms. > > I would say that if the WG didn't think it was important at the time by > forgetting it, it probably is not an "important term", and I can see > this not being fixed in an IETF LC anymore as an acceptable outcome. > > Especially as the DNS Terminology document seems to be getting refreshed > pretty regularly to begin with. > > But also, I didn't find a good definition of round robin in existing > RFCs either. There is a mention in rfc1794 but it doesn't really define > the term there. So I am not sure what the DNS Terminology document would > reference? > I agree. My personal experience is that it isn't a widely used term and it's been more than a decade since I last heard it. The fact that no-one even brought it up at any point during the development of this doc or its predecessors seems to confirm that. Back then, my recollection was there were 2 distinct meanings of round robin DNS: the first was simply a Resource Record Set with multiple Resource Records in it, where the DNS server returned the constituent records in the RRset in a rotated or shuffled manner. That is in fact the typical behavior of many current DNS implementations, so I think that is already covered by the inclusion of the term RRset in the document. The second meaning was from implementations that selectively returned one record from the RRset in the answer, and rotated the selection of that record in response to successive queries. By spec, since RRsets are "atomic" units where all the records have to be returned in the response, this is an example of a non-standard DNS trick. There are many other examples of such non-standardized response generation mechanisms (GLSB, weighted answers, etc), and none of those are documented in the DNS terminology BCP. It would probably not be appropriate to do so. If necessary, those could be documented separately in an informational document. Shumon. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-dnsop-multi-provider-dnssec-04
On Wed, Apr 8, 2020 at 10:24 PM Alissa Cooper wrote: > Pete, thanks for your review. Shumon, thanks for your response. I entered > a No Objection ballot. > Thank you Alissa! ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-dnsop-multi-provider-dnssec-04
On Tue, Mar 31, 2020 at 6:10 PM Pete Resnick via Datatracker < nore...@ietf.org> wrote: > Document: draft-ietf-dnsop-multi-provider-dnssec-04 > Reviewer: Pete Resnick > Review Date: 2020-03-31 > Summary: Ready. > > Good to go. A straightforward document easy enough for this non-expert to > get. > Thanks to the shepherd for a straightforward writeup; it made the review > even > easier. > Hi Pete, Thanks for your review. > Major issues: None > > Minor issues: None > > Nits/editorial comments: > > Just two comments, neither of them should stop progress on the document in > any > way: > > 1. I could see this document being a BCP, since the advice in here seems > pretty > prescriptive. I think it will still be perfectly useful as an Informational > document, but it does seem to have important operational advice. > When we first brought this work to DNSOP, I actually asked the same question. The general consensus at that time was that since no-one had yet deployed these models in production, it was probably premature to portray it as a BCP (since the practice did not yet exist :-). By now, we have had a number of prototype/test implementations, a production implementation by one major DNS vendor, as well 2 others in the pipeline. So there is more confidence that these models will be successfully deployed. The easiest course of action in my view is to push it out as Informational, and as more operational experience is gained in the field, produce an updated document as a BCP. 2. In section 3, it occurs to me that another thing you might add to the > problem list is the issue of some servers caching BAD Data. Paul Hoffman > was > nice enough to point me to section 4.7 of RFC 4035. Perhaps a reference to > there from this document would be useful. > I'm pondering a bit more about what to do with this suggestion. I agree it might be worth mentioning. Although I'm not sure there is any new behavior w.r.t. these models that needs to be highlighted. Again, take them for what they're worth. If you decide not to do either, I > feel > the document could go forward as-is without a problem. > Thanks! Shumon Huque ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart telechat review of draft-ietf-tls-dnssec-chain-extension-06
On Tue, Feb 6, 2018 at 8:25 PM, Matthew Miller < linuxwolf+i...@outer-planes.net> wrote: > Reviewer: Matthew Miller > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-tls-dnssec-chain-extension-06 > Reviewer: Matthew A. Miller > Review Date: 2018-02-06 > IETF LC End Date: 2018-02-07 > IESG Telechat date: 2018-02-08 > > Summary: > > This document is ready, with one issue that I think could benefit > from some clarification. > > Major issues: > > NONE > > Minor issue: > > This is more a question, that might warrant some clarification: > In 7. Verification, the last paragraph discusses client-side > caching of the RRsets. If a client has cached the full RRset chain > from TLSA to root RRSIG (and that cache is still viable), is the > client still expected to specify the "dnssec_chain" extension? > > In my reading, that does not seem necessary, and I think it might > be worth noting if that is true. > Yes, if the client has cached either the validated TLSA RRset or the full chain, then it doesn't need to send the dnssec_chain for subsequent connections. If it has only cached other portions of the chain, then it needs to. We can clarify this. Shumon Huque ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
