On Thu, Nov 21, 2019 at 4:19 AM Petr Špaček <[email protected]> wrote:
> On 21. 11. 19 9:49, Wes Hardaker wrote: > > Wes Hardaker <[email protected]> writes: > > > >>> I think our simplest and most appealing option would be to treat EDE > >>> exactly like any existing EDNS Option (i.e. set the TC bit). > >> > >> For the record, I'm just fine with this. People that *want* a separate > >> signal should speak up please and voice their reasons why having just > >> the TC bit is unacceptable too. > >> > >> We need to come to a decision about this, and that will require everyone > >> with an opinion to chime in. > > > > Actually, I forgot that one of the primary reasons for separating it was > > that EDE can go forward and the need for TC/DP bits can be debated > > longer if need be. > > > > So... anyone that thinks something like the DP bit is needed *and* > > should be tied to EDE should speak up. Please. > > I will provide the opposite opinion: > DP bit is not *needed* for EDE. > > If I'm proven wrong in future we can specify DP bit in a separate document > and update EDE RFC. > > (Also I've changed my mind when it comes to TC bit - now I believe that > normal DNS processing is fine and EDE does not need a special case.) > > -- > Petr Špaček @ CZ.NIC > Thanks for the discussion and the idea of a separate bit. My opinion: Keep TC bit in EDE and move it forward. I would prefer not to create a DP flag bit yet, until actual measurements tell us that it makes a measurable difference - let's wait until EDE is deployed and someone can measure the occurrence of truncating just EDE. Then we can discuss if the percentage is worth the complexity. -- Bob Harold
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
