Re: [mif] New revision of DNS server selection

[<[e-mail]>]

> On Nov 11, 2010, at 5:53 PM, <[e-mail]> wrote:
> > But then elsewhere people say network knows always better:) I'm
> confused of IETF:)
> > The user can fallback to use single interface.
> 
> How would the user know to fall back to a single interface?

How would the user know the network is instructing DNS queries should go over one interface or another at the first place?
 
> I argued earlier that using DNSSEC without this draft was a better
> solution than this draft.   I still think that's the case.   The

You also said:"DNSSEC doesn't remove split-horizon problems." So you say DNSSEC does not remove problems but is better solution than this. I have some hard time following the thinking and what the solution with DNSSEC would look like. Here I assume DNSSEC != send queries to all DNS servers.

> problem with recommendations of this sort is that they aren't
> enforceable, and aren't likely to be followed.  If, in order to get the
> behavior you want, you *have* to sign the zone, then that's more likely
> to happen.   So while I agree that a *requirement* to use DNSSEC here,
> if followed, would solve the problem, I don't think that the suggestion
> in the spec is going to help very much.

IETF cannot force implementation of anything that doesn't make sense in deployment at hand. Having DNSSEC MUST is pointless if there are imaginable real deployment scenarios where DNSSEC is just not needed - and where implementers can make the judgment call to not do DNSSEC if they know it is not needed. That way people who want security get it, but others can opt-out without violation MUST. But if you wish, we can have that MUST and the ignore in implementation phase:)

> You are talking about the situation where the ISP controls the device
> that's doing the protocol then, right?   Traditionally the way we've
> done stuff like this is to put it in a cablelabs encapsulation; that
> way the people who need it for boxes they control have a clear
> specification, but it's not implemented on devices to which that
> specification doesn't apply (e.g., my iPad).

This is the first time I hear that any DHCP option we specify gets implemented into iPad! Seriously, I'm sure you know people implement IETF specifications only when it makes sense for them (and sometimes don't implement even if it would have made sense, like we see in the level of IPv6 support in various places).

We are chartered to work on DHCP. We might be able to do this feature with things like ANDSF, 3GPP PCO IE, cablelabs, and so on, but is it really worthwhile to define same thing all over again in those places? Why not implement in DHCPv6 instead and then implement the DHCPv6 RFC on those devices where it applies. 

Best regards,

	Teemu