Earlier, Dino Farinacci wrote: % 1) If you put Loc/ID functionality in hosts, then they % will have to change. Don't want to do this because % it kills deployability.
This question, for which Dino's view is expressed above, is actually pretty central to the discussions here. A) Some folks on this list (e.g. Dino) believe that the Routing RG cannot select an approach requiring any host stack changes -- because that necessarily precludes deployment. B) Other folks on this list (e.g. Jari) believe that the Routing RG can select an approach requiring host stack changes because that is done by the IETF in the ordinary course of IETF work. This is a fundamental difference in perspective and deserves further discussion and thought by all. If (A) is true, then certain proposals are ruled out by definition. If (B) is true, then all proposals are really open for adoption. I'm not sure what the RG Chair(s) think, I'm not sure what host stack implementers think, and I'm not sure what the IETF Powers-that-Be think while wearing their official hat(s). As a purely practical matter, at least one host OS implementer has a de facto veto on this question. If that host OS is not going to adopt a proposed host stack modification (or not adopt it in a timely way), then the percentage of deployed host OSs with the upgraded stack capabilities is very unlikely to become commercially interesting/viable. 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
