In message <1321238859.2514.73.camel@karl>, Karl Auer writes:
> 
> On Mon, 2011-11-14 at 10:27 +0800, Ole Troan wrote:
> > can you give examples of what information cannot be merged?
> > certainly a default router list can be merged...
> 
> If one source says that the domain search list is "a.com b.com c.com"
> and another source says it is "c.com a.com b.com", how can you merge the
> search lists?

Anyone depending apon search lists that they did not set already
has a broken configuration.  Anyone depending apon search lists in
RA's or DHCP messages being honoured by machines already has a
broken configuration.

Search lists are things that should be set by users for themselves.

ISP's SHOULD NOT be setting search lists in DHCP responses to
customers.  Hotspots's SHOULD NOT be setting search lists in DHCP
responses to customers.

Enterprises MAY advertise a search lists when configuring their own
machines.  Homes MAY advertise a search lists when configuring their
own machines.

Enterprises and homes SHOULD NOT set search lists when responding
to DHCP queries on guest networks.

Similarly for RA's.

> Or if one source says that the default route is via IP address 1, and
> the other source says that the default route is via IP address 2, which
> IP address are you supposed to use as your default route? Sure, you can
> set up two default routes - but when a packet turns up for which you
> have no more specific route, which IP address will you send it to?
> Something has to choose, using some criterion or other.

If they are both true "default routers" then it doesn't matter which
you send to.  If they are not then there is nothing a machine can
do automatically.

> Some things cannot be merged - that's what "conflict" means.
> 
> Regards, K.
> 
> --=20
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Karl Auer ([email protected])                   +61-2-64957160 (h)
> http://www.biplane.com.au/kauer/                   +61-428-957160 (mob)
> 
> GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
> Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
> 
> --=-dBD+3PSBkGldJAphgaQ5
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: This is a digitally signed message part
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> 
> iEYEABECAAYFAk7AgUsACgkQMAcU7Vc29od/4QCbBqCgnAOZiE0+zx3l0VFFGP+2
> D0YAnjVCFgBd5WbgE1alnPfi/01lnfQm
> =zTr6
> -----END PGP SIGNATURE-----
> 
> --=-dBD+3PSBkGldJAphgaQ5--
> 
> 
> --===============7419444934332968338==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
> --===============7419444934332968338==--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email protected]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to