On 11/21/2019 1:53 AM, Wes Hardaker wrote:
During the first DNSOP meeting at IETF 106 there was a discussion that
had multiple opinions about what to do with setting the TC bit for EDE
information, which is generally supplemental. During my presentation I
mentioned that an associate of Viktor suggested creating a new bit, and
during the conversation there was discrepancy about whether or not that
was a good idea. Brian Dickson then proposed that the new bit only
modify future clients that wanted to use it, thus leaving the EDE spec
setting the TC bit. A future bit could be defined that would indicate
that only supplemental information was dropped.
My proposal for EDE is that we follow this train of thought, which seems
to be the widest idea accepted from what I could tell. TLDR for things
to do:
1. We have the EDE document say to set the TC bit (which it already did)
2. We create a new document that defines an extra bit for indicating
that the dropped information was supplemental and didn't contain
operationally important information.
If this sounds like a good compromise, great! If you would like to
propose an alternative, great! do so!
From 2181:
The TC bit should be set in responses only when an RRSet is required
as a part of the response, but could not be included in its entirety.
The TC bit should not be set merely because some extra information
could have been included, but there was insufficient room.
I finally got a chance to go back and do some reading and found the above.
The way I read this is that setting the bit simply because you couldn't
include diagnostic info is a no-no. Let's not do it.
I read "required" not as "the querier (person) requires it" but as "the
protocol requires it".
So - 3rd (4th?) option. Include a bit in querier EDNS(0) that says
"set the TC bit if I dropped EDE" and maybe "return the EDE info that
was dropped instead of or in preference to the query response data".
Later, Mike
In the mean time, I threw together a quick ID for the new bit as well:
https://datatracker.ietf.org/doc/draft-hardaker-dnsop-drop/
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
