Are you saying multiple addresses on one interface of the host? thanks -Hui 2009/4/21 Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx>: > Jari Arkko wrote: >> There has been some discussion on whether the key issue is merging >> configuration from multiple sources (the "DHCP view"), multiple >> interfaces (the "original view"), multiple default routers (the "routing >> view"), multiple addresses (the "IP layer view"), multiple >> administrative domains (the "operational view"), and so on. >> >> I would like to make the point that there is no single, perfect answer. >> Its easy to find examples where the key issues above do not capture >> everything that we want to capture (see, e.g., George's response to >> Keith). Its really about the combination of these issues. And I think >> that is the way it should be. >> >> The charter text that I sent out yesterday attempts to explain what the >> problem space is without prejudicing ourselves to a view from just one >> perspective (except perhaps through the group's acronym). I think the >> rest is work on the problem statement, and we should let the group write >> that. >> >> The IESG telechat where this could be approved is two days away. Does >> someone have a big problem with the charter as written, serious enough >> to warrant a change? > > 1. I really think that the emphasis on "attachment to multiple networks" > is too narrow, as this is far from the only source of the problem. As > long as the WG is just trying to understand the problem and identify > existing solutions, it seems appropriate to broaden the scope to > consider the more general problem of multiple addresses per host. > > 2. I also think that, when considering the effect on applications, it > needs to be explicitly pointed out that p2p and distributed apps need to > be considered separately from client-server apps that many people regard > as representative. > > More generally I think that various kinds of effects need to be > considered (i.e. not just the effects on applications) and it would be > very helpful if the charter could lists some examples of these as > illustrations of the breadth of scope. That would minimize the > potential for the WG to start off with many participants thinking "_the_ > problem is X" when the actual problem is much broader.... and hopefully > get the WG in the mode where it tries to enumerate the various problems > and impacts rather than to try to nail down _which_ problem it is and > ignore the others. > > 3. I am a bit concerned by the charter's mentioning of BCP documents as > a possible output from the WG. I thought I had seen language in the > charter text saying that the group should write a BCP, but either I was > mistaken or that language has since been removed. But there's still a > BCP mentioned as a deliverable in the milestones. My concern is that > the WG will take this as license to try to define best current practice, > which I think is somewhat of a conflict of interest with trying to > identify the problem - especially given the broad scope. > > Keith > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf