Re: problems with draft-ietf-ipv6-deprecate-rh0-00.txt

[Jari Arkko <jari.arkko at piuha.net>]

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 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------