Re: [DNSOP] Consensus suggestion for EDE and the TC bit

My preference is also to not add the DP bit as part of the EDE
feature. We should gain more experience with EDE before adding any new
bits to the protocol.

On Mon, Dec 2, 2019 at 1:55 PM Eric Orth
<ericorth=40google.com@dmarc.ietf.org> wrote:
>
> I still have a soft preference (but am definitely not going to call it a hard blocker) for some way to avoid followup queries when the only thing causing truncation is EDE.
>
> My concern comes from the EXTRA-TEXT being an open-length field, and I imagine many operators would want to create long verbose error messages.  Seems that could lead to many cases where EDE causes common excessive truncation.
>
> Maybe an alternate easy solution would be to add a don't-do-that note to section 3.4 along the lines of "Long EXTRA-TEXT fields may cause truncation and bad resolve performance, which is usually undesirable for the supplemental nature of EDE. Operators setting the field SHOULD avoid setting unnecessarily long contents, especially when it can be determined that doing so will cause truncation." With something like that, I think my concerns are enough resolved that I wouldn't worry about DP unless future experience shows EDE truncation to be a significant problem.

I would support text like the above in section 3.4 to remind operators
not to put very long text in the EXTRA-TEXT field.

>
> But otherwise, if people don't like my suggested note, because I only have a soft preference to do something, I agree that moving TC/DP to a separate doc is a good idea.  If EDE is otherwise consensus-ready, let's get it published.
>
> On Thu, Nov 21, 2019 at 12:04 PM Ray Bellis <ray@bellis.me.uk> wrote:
>>
>>
>>
>> On 21/11/2019 15:37, Ben Schwartz wrote:
>>
>> > I would suggest adding a requirement to the EDE draft that EDE be
>> > the last option in OPT
>>
>> And what if some other future option wants to lay claim to that requirement?
>
>
>  I agree that this would be a difficult requirement to set.  Only one thing can be last, and I would argue that EDE is not important enough to claim that distinction and take away the flexibility from future specs.
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop