% Just to clarify: do you mean that "fix naming" is not in any % of the branches mentioned in my msg?
Yes. % Here is my personal view: % - naming on Internet is a very important issue. Agree. % - it is also very broad, concerning multiple layers of the % protocol stack. That claim is not necessarily true. % - there are inter-dependencies between naming at diff layers. At present, this is often the case, but is not always the case. It is not necessarily true going forwards. % - In solving the routing scalability problem, % we need a clear understanding of, as far as naming is concerned, % (a) what we depend on the lower layers % (b) what we may affect on the higher layers I can't follow the above. % - It is beyond our charter to offer a solution for the % naming problem across all the layers of the protocol stack. That is not obvious from a plain reading of the current charter. In any event, there are architectural concepts that might be applied that would not require ALL layers of naming to change. % - IP/routing layer solution should focus on our own problem at hand, % once we make the design decision here, we'd be in much better % position to handle upper layer naming issues. The defined problemS in the charter, all of which are in scope, go beyond site multi-homing to explicitly include other things (e.g. mobility). ALL of the problems in the RG charter need to be addressed, not just the site multi-homing issue. As an example, reading IEN-1 might suggest that modifying the sundry transport-protocols to not include location information in the pseudo-header is one possible solution approach. (It might or might not be the *preferred* approach, but that is a separate question.) That approach is neither translation, nor map-and-encap, nor .... Yours, Ran [EMAIL PROTECTED] -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
