Re: [DNSOP] DNSOP rfc8499bis Interim followup consensus on historical definition of bailiwick
On 11/3/22 17:44, Benno Overeinder wrote: Questions: 1. Move Bailiwick to historical. 1a. During the interim, there was a (feeling of) consensus to drop a formal definition of "bailiwick", but keep a historical definition (how it was interpreted by) of "bailiwick". Also do not define and use the term "in-bailiwick". Suggested terms to use are "in-domain name server" and "sibling domain domain server", as defined and used in draft-draft-ietf-dnsop-glue-is-not-optional, section 2.1 and 2.2. [The latest draft of glue-is-not-optional does provide a definition of sibling domain name servers, but it does not really provide one for in-domain name servers. That would be easy to fix.] 1b. Does this also mean changing the definition of "out-of-bailiwick" to a more historical definition as well? Or do we still need a term for in-domain name server, sibling domain name server and ... (alternative for out-of-bailiwick)? Is "unrelated name server" a term that can be used? I think "unrelated name server" is easy to misunderstand, as the term is unclear about what kind of relation it refers to. For example, a naive interpretation of an "unrelated" nameserver may be a sibling nameserver that is operated by another (unrelated) DNS provider. I would think that such misunderstandings will be frequent when this term is introduced. Think about various degrees of relationship, the following observation occurred to me. - in-domain nameservers are, in a sense, related to the 0th order (no delegations not shared between zone and NS), - sibling nameservers are related to 1st order (one delegation not shared, namely the one from the parent to the NS zone), - out-of-bailiwick nameservers are related to 2nd or higher order (example.com with ns1.example.net has 2 delegations not shared, namely the net delegation and the example.net delegation). One possible would thus be to establish terminology in terms of n-th order. E.g., sibling NS is a "1st-order foreign delegation NS" or something like that. -- I'm aware this sounds very bumpy, and it's simply what just occurred to me, not at all thought through. I'm also not trying to crash the interim results, just sharing the observation. If not helpful, ignore. :) Best, Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOP rfc8499bis Interim followup consensus on glue definition
On Thu, 3 Nov 2022 at 21:49, Benno Overeinder wrote: > >8 > > Q2. Definition of Glue provided by Duane Wessels on the DNSOP WG mailing > list: > > "Glue is non-authoritative data in a zone that is transmitted in the > additional section of a referral response on the basis that the data > might be necessary for resolution to proceed at the referred name > servers." > > On the mailing list, we have seen a discussion about "necessary" > versus "useful". In this context glue is defined to be exclusively > A/ records (traditional understanding), or do we also consider > other RRtypes to be glue, e.g. SCVB/HTTPS or DS records? Concern is > that "useful" may lead to a definition that is too broad. > The ink is not yet dry on SVCB/HTTPS. I fail to see why DS would be a part of this topic. Suggest the following redrafting to make explicit what it is and why it is needed: "Glue is the set of non-authoritative A/ records in a zone that are transmitted in the additional section of a referral response on the basis that these might be necessary for a resolver to reach the target name servers." Regards --RWF ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Probably not a new thing (was Re: New agenda, and alt-tld draft at IETF 115)
Dear colleagues, [I'm employed by the Internet Society, and not speaking for them.] On Wed, Nov 02, 2022 at 09:27:33PM +, Suzanne Woolf wrote: The chairs set out some comments on the -17 version, which appear to have been addressed in the -18 version. We agree with the editors that there are a couple of issues that may need further discussion. The time set aside for alt-tld in our meeting next week is intended to let us we find out how far we might be from consensus on the current draft and whether people still feel there are new things to say. In the interests of not taking up meeting time, I thought I'd send a note here to say that I think the current draft addresses such concerns as I had. There are several things it does _not_ do that I think are important. It does not specify anything about the wire or presentation format of possible names in this space. It does not constrain the names in any way with rules about DNS or its restrictions or so on. And it does not create any registry and just accepts that those wishing to use this unmanaged namespace are on their own and had better be prepared to deal with that. The reason I think all of that important, in case it wasn't clear in previous stuff I said, is that I conceive of this space as entirely dedicated to the idea that there are other potential naming systems that are quite purposely trying to address limitations in DNS. They will therefore, of necessity, possibly be incompatible with any DNS limitation. If this namepsace is constrained by DNS limitations, that will encourage people to avoid this namespace, and so the goal of its creation would be undermined. The reason I think the lack of a registry to be good is that it makes quite clear that nobody can rely on a registry as somehow authoritative for this namespace. The danger with a registry is that people treat it as authoritative and therefore attempt to legislate deference to the registry. But we know that at least some experiments in naming are explicitly disdainful of the idea of authoritative registries. Such efforts almost certainly will not register their presence, and so every protocol will need to cope with collisions anyway. If that is true, then a registry has minimal technical value and has a potential technical harm. I therefore support proceeding with draft-ietf-dnsop-alt-tld-18. It is admittedly imperfect, but it is addressing an area where perfection is fundamentally impossible. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] DNSOP rfc8499bis Interim followup consensus on glue definition
Dear WG, With the DNSOP rfc8499bis interim in September, we had the action point to send two questions to the DNSOP WG to find consensus on the bailiwick and glue discussion. You can find the interim meeting material here https://datatracker.ietf.org/meeting/interim-2022-dnsop-02/session/dnsop and the recording of session here https://youtu.be/wY7-f40lDgU. This is the second email to the WG, focussing on the definition of glue. Questions: 2. Definition of Glue provided by Duane Wessels on the DNSOP WG mailing list: "Glue is non-authoritative data in a zone that is transmitted in the additional section of a referral response on the basis that the data might be necessary for resolution to proceed at the referred name servers." On the mailing list, we have seen a discussion about "necessary" versus "useful". In this context glue is defined to be exclusively A/ records (traditional understanding), or do we also consider other RRtypes to be glue, e.g. SCVB/HTTPS or DS records? Concern is that "useful" may lead to a definition that is too broad. Taking the last point a step further: if the definition is expanded and glue-is-not-optional becomes a requirement then responses may grow in size and exceed fragmentation/truncation thresholds and lead to more TCP. Remark by WG during interim meeting: One might need a registry for RRtypes being glue (in the future). Thanks, -- Suzanne, Tim and Benno ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] DNSOP rfc8499bis Interim followup consensus on historical definition of bailiwick
Dear WG, With the DNSOP rfc8499bis interim in September, we had the action point to send two questions to the DNSOP WG to find consensus on the bailiwick and glue discussion. You can find the interim meeting material here https://datatracker.ietf.org/meeting/interim-2022-dnsop-02/session/dnsop and the recording of session here https://youtu.be/wY7-f40lDgU. We will send two questions to the WG, in two separate emails to keep the discussion separate. This email is the first question to the WG that addresses the definition of bailiwick. Questions: 1. Move Bailiwick to historical. 1a. During the interim, there was a (feeling of) consensus to drop a formal definition of "bailiwick", but keep a historical definition (how it was interpreted by) of "bailiwick". Also do not define and use the term "in-bailiwick". Suggested terms to use are "in-domain name server" and "sibling domain domain server", as defined and used in draft-draft-ietf-dnsop-glue-is-not-optional, section 2.1 and 2.2. [The latest draft of glue-is-not-optional does provide a definition of sibling domain name servers, but it does not really provide one for in-domain name servers. That would be easy to fix.] 1b. Does this also mean changing the definition of "out-of-bailiwick" to a more historical definition as well? Or do we still need a term for in-domain name server, sibling domain name server and ... (alternative for out-of-bailiwick)? Is "unrelated name server" a term that can be used? Thanks, -- Suzanne, Tim and Benno ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
