This is one of those times where classic email quoting isn't helping my brain. Maybe I'm alone, but I think there may be others in a similar situation.
We're close to a discussion of very specific language. I think the best thing is for people to state once, in their level of indentation (ie "top") *EXACTLY* what specific language they think we need here. Say the text. All of it (that you want to discuss) as you want it to be in the document. Even if it becomes repetitious, I am struggling to maintain context over the words and what they mean, under the latest edit. cheers -G On Thu, Dec 16, 2021 at 10:09 AM Tim Wicinski <tjw.i...@gmail.com> wrote: > > > (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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
