Jan> There might be concerns that poorly written network applications will
Jan> need to depend on milestone/network because they will fail if they don't
Jan> find certain peer.
Sebastien> You stated that the reason you're keeping milestone/network is
Sebastien> to appease applications that depend on reachability to their peers,
Sebastien> and do this by depending on milestone/network.
No; as both of you know, English is a confusing language, hard to learn as
it is easily given to ambiguities. In this case, what I think Jan meant was
something more like:
We need to keep milestone/network for backwards compatibility, as
certain applications may have been written to depend on the service.
(One reason for such a dependency might well be a misguided idea
that it would ensure the ability to reach certain peers.)
In other words, we are not keeping the service because of the indirect ability
to reach peers, but because of the direct compatibility issue which would be
caused if we were to remove the service.
Sebastien> The NWAM design seems to place all configuration of data-links and
Sebastien> IP interfaces as part of a LLP, and an IP tunnel is definitely
Sebastien> both of those things. So, according to the design, an IP tunnel
Sebastien> should be part of a LLP. At the same time, the NWAM architecture
Sebastien> describes an upper-layer profile as something that defines a
Sebastien> set of things that happen under certain conditions, such as the
Sebastien> configuration of IP addresses in a particular subnet, or which
Sebastien> physical links are connected. It would make sense to make the
Sebastien> configuration of an IP tunnel conditional on such criteria.
You are following our architecture/design correctly so far.
Sebastien> As such, I don't see the LLP vs. ULP distinction as being very
Sebastien> clear cut for IP tunnels, and I think I'd benefit from a whack on
Sebastien> the head by a heavy clue stick. :-)
No, you don't need a whack; you have pointed out a gray area which we have
been trying to resolve. Stay tuned for more on this...
-- John
http://blogs.sun.com/jbeck
