It's never been up to the DHC working group to decide whether new DHCP
options are architecturally good.   People have often used the DHC working
group as a way to skate by due diligence on architectural considerations;
this was considered to be a problem even before I was chair, and we burned
a lot of time evaluating bad ideas before we decided not to be the place
where new work on DHCP options is done by default.   If a DHCP option were
to be entertained, this WG, the dprive WG or the DoH WG would be where it
would have to happen, not because the DHC working group is freezing new
features, but because it's not in their charter.

That said, you responded to a message where I talked about what I think we
ought to do to move forward by saying that moving forward is impossible
other than by just adding a hack somewhere.   I don't think that's true,
and in fact I'm feeling like I need to write up a threat analysis because
even though it's not something that I want to work on, it sounds like most
people assume it's impossible and I'm just suggesting it as a roadblock,
and the people who get that it's necessary don't seem to be any more
enthusiastic about doing it than I am.   I'd appreciate it if, when I've
written that analysis, you could contribute to it, but I'll understand if
you don't have time or don't think it's worthwhile.

On Wed, Aug 22, 2018 at 2:24 PM, Paul Vixie <[email protected]> wrote:

>
>
> Ted Lemon wrote:
>
>> Again, to repeat myself once more, one more time, I am asking that we
>> actually decide what to recommend, and not just say "we all already all
>> know what the right behavior is."   If we all agreed on what the correct
>> behavior was, we wouldn't be having this discussion.   Maybe if we tried
>> to describe what we all think the correct behavior was, we would realize
>> that we do agree on it, but we haven't done that yet.   And the possible
>> set of all behaviors is more complicated than you suggest.
>>
>
> with regard to dhcp, if the dhc wg is freezing new features pending
> authentication capabilities which are not forthcoming, then dhcp is off the
> table for DoT discovery.
>
> in that case, the purported android approach of "use DoT if it works" may
> be the only way forward. this means when current unauthenticated dhcp tells
> you what your rdns servers are, you'll try each of them with TCP/853 and
> use that if it works, else fall back to whatever you did before, which is
> probably UDP/53 falling back to TCP/53.
>
> --
> P Vixie
>
>
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to