Change:
writing, this configuration has been corrected and the response correctly sets the TC=1 flag. <del> DNS responses sometimes contain optional data in the additional section.  Glue records however are not optional.  Several other protocol extensions, when used, are also not optional.  This includes TSIG RFC2845, OPT RFC6891, and SIG(0) RFC2931. </del> <ins> 3. Replace "Copy the NS RRs for the subzone into the authority section of the reply.  Put whatever addresses are available into the additional section, using glue RRs if the addresses are not available from authoritative data or the cache.  Go to step 4." with </ins> <del> 3.2. </del> <ins> "Copy the NS RRs for the subzone into the authority section of the reply.  Put whatever addresses are available into the additional section, using glue RRs if the addresses are not available from authoritative data or the cache.  If all glue RRs do not fit, set TC=1 in the header.  Go to step 4." </ins> <del> Sibling glue are glue records that are not contained in the delegating zone itself, but in another delegated zone.  In many cases, these are not strictly required for resolution, since the </del> <ins> 4. Sibling glue are glue records that are not contained in the delegated zone itself, but in another delegated zone from the same parent.  In many cases, these are not strictly required for resolution, since the </ins> resolver can make follow-on queries to the same zone to resolve the nameserver addresses after following the referral to the sibling <del> zone.  However, most nameserver implementations provide them as an optimization to obviate the need for extra traffic. </del> <ins> zone.  However, most nameserver implementations today provide them as an optimization to obviate the need for extra traffic from iterative resolvers. This document clarifies that sibling glue (being part of all available glue records) MUST be returned in referral responses, and that the requirement to set TC=1 applies to sibling glue that cannot fit in the response too. </ins> <del> Question: if sibling glue from the same delegating zone does not fit into the response, should we also recommend or require that TC=1 be set? </del> <ins> 4.1. </ins> <del> 3.3. </del> <ins> Here the delegating zone "test" contains 2 sub-delegations for the subzones "bar.test" and "foo.test". </ins> <del> Here is a more complex example of sibling glue that lives in another zone, but is required to resolve a circular dependency in the zone configuration. </del> <ins> Referral responses from "test" for "foo.test" must include the sibling glue (and set TC=1 if they do not fit): </ins> <del> 3.4. </del> <ins> 5. </ins> When a zone is deleted but the parent notices that its NS glue records are required for other zones, it MAY opt to take these (now orphaned) glue records into its own zone to ensure that other zones <del> depending on this glue are not broken.  Technically, these NS records are no longer glue records, but authoritative data of the parent zone, and should be added to the DNS response similarly to regular glue records. </del> <ins> depending on this glue are not broken.  Technically, these address records are no longer glue records, but authoritative data of the parent zone, and should be added to the DNS response similarly to regular glue records. </ins> <del> 4. </del> <ins> 6. </ins> This document clarifies correct DNS server behaviour and does not introduce any changes or new security considerations. <del> 5. </del> <ins> 7. </ins> There are no actions for IANA.

Discussion:
Misc updates .. Rework Sibling Glue section, and clarify that they MUST be included, and also subject to TC=1 if they don't fit. Remove the cross parent zone cyclic dependency example, which doesn't work (I think we agreed to that, but I can be persuaded to add it back, if we want to point out a misconfiguration as a warning). Move the paragraph about non-optionality of types of additional section data into the tail end of the Intro. It deserves to be more prominently mentioned than buried at the end of the example of missing glue. Addressed Duane's comment that the "Why is Glue Required?" section did not actually say why, but instead just gave examples. Instead, I added a one phrase explaining why to the Intro section that defines glue records. I don't think it requires a separate section. Removed Duane's comment about "I think the document should say that some servers might experience an increase in TCP if implementations require all glue or set TC=1. If not in this section then somewhere else._". I agree we should address this, so I've made an "issue" for it. And we can add the relevant text in the next update, once we figure out where it goes (an "Operational Considerations" section perhaps?).
NAME - added your tweaks. Please review/approve!