(no hats) I feel that "might be useful" leaves the definition still ambiguous.
I like Paul V's additions on where the glue must reside, and noting that it will be passed along with transfers. tim On Wed, Dec 15, 2021 at 6:56 PM Wessels, Duane <dwessels= 40verisign....@dmarc.ietf.org> wrote: > For me “necessary” is an important distinction and “might be useful” is > too broad or ambiguous. I have a hard time reconciling the idea that glue > is not optional with the idea that it might be useful. > > DW > > > > On Dec 15, 2021, at 3:18 PM, Ben Schwartz <bemasc= > 40google....@dmarc.ietf.org> wrote: > > > > > > > > I like this definition. However, I think it would be clearer to say > "useful" instead of "necessary". > > > > On Wed, Dec 15, 2021 at 1:18 PM Wessels, Duane <dwessels= > 40verisign....@dmarc.ietf.org> wrote: > > Despite what the subject line says, I’d like to follow up on the > discussion about glue from today’s interim meeting. > > > > First, I think the definition of glue given in RFC 2181 is problematic > in a number of ways. It is overly broad (e.g., "any record ... that is not > properly part of that zone” and "any other stray data that might appear”). > It essentially says that all non-authoritative data is glue, including NS, > which is wrong IMO. > > > > If we can ignore what 2181 says, then the question is whether or not > glue is limited only to addresses. Historically it has only meant > addresses, since those address RRs were required for zones with in-domain > name servers. There are some new proposals in DPRIVE to publish more > record types in parent zones and have them considered as glue. This has > obvious implications server behavior given the glue-is-not-optional draft. > > > > On one hand I think it would be a lot simpler to just say that only > address records can be glue. But I’m not sure that is defendable given the > directions things are going. Here’s a definition of glue that I came up > with: > > > > 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. > > > > I also feel like we might be heading in a direction where there would > need to be a registry or some standardization of which RR types can be > treated as glue. > > > > DW > > > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
