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
