Since John formulated this summary and suggestion almost a week ago,
there has been no comment. Nix, nada, zilch.
It does reflect suggestions made in passing in several other messages,
but I feel that it is important enough that needs to be an explicit
decision made on the suggestion.
If there are no further messages on this issue, the *default* decision
will be "no change".
Tony Hansen
tony(_at_)att(_dot_)com
John C Klensin wrote:
Hi.
This has been discussed, but just to give it a number and insure
that it doesn't fall through the cracks...
2821 sort of danced around the issue of source routes, going a
little further than 1123 did in discouraging their use but not
getting rid of them entirely. The method used to do this in
2821 is a little fuzzy, since it left the text in place
instructing relays to copy their own domains into the
backward-pointing address. That was discussed as issue 26 and
the working draft for -03 now has that issue straightened out
(assuming I've gotten it right).
However, that discussion raised another possibility, which is
that now is the time to deprecate source routes entirely. More
precisely that would:
(i) Leave the syntax in place and continue to require
that systems be able to accept and parse it.
(ii) Forbid systems from using source routes, either
changing the "they should be ignored but may be used"
language that now appears in Section 3.3 (and more or
less repeated in 3.6) to forbidding their use for
routing or leaving those two sections alone (I consider
eliminating the redundancy to be an editorial matter if
I can figure out how to do it).
(iii) Continue with (ii) by changing the "SHOULD not
generate" in the second paragraph of 4.1.1.3 to MUST NOT.
(iv) Get rid of Appendix C, replacing it with some
handwaving to the effect that, if people really need to
know how this obsolete feature worked, they should read
821.
(v) Strengthen the prohibitions in Appendix F.2.
So far, we've heard from a couple of people on-list who feel
that this is a much better idea than the patching contemplated
by issue 26 and no one who has argued for keeping them. Whether
it is realistic to further deprecate them or not probably
depends on interoperability testing although we could arguably
prohibit the things as a bad idea that is not widely supported.
john