Iljitsch, > In short: the draft uses undefined terminology, does more than it is > supposed to do, provides no explanation of any kind but rather refers > to an external document that is high on rhetoric
If there is rhetoric, lets get rid of it. Please suggest specific changes. > - the draft "deprecates" the routing header type 0 without explaining > what deprecation entails ... > ... define what "deprecate" means and then what deprecation of the > routing header type 0 means in practice, and how this solves the > problems explained earlier. Or we simply forego use of the word > "deprecate". > Its a good question what deprecation means. I have personally taken it to mean "act as if it didn't exist in the first place". As the draft explains, nodes should behave as if they did not recognize type 0 at all. I think that is a good starting point, for both receiving and sending. (The current draft goes a bit beyond this, however, in having the two MUST NOTs in Section 3. I'm not sure this is a problem -- the formulation is up to the WG.) > I would also like to see a discussion of source routing in IPv4 > included here, contrary to popular belief source routing for IPv4 is > enabled on a good number of routers, and relatively recent software > from one popular vendor still has IPv4 source routing enabled by default. Yes - we need to do this, too. RFC 1812 still requires processing to be by default on for routers... (But lets do it in another document.) Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
