The whole story about deprecating Site Local has led to very complex discussions
that a lot of people had difficulties to follow, partly because the issues are complex
and partly because of the heat of the debate.
As we are coming near to a conclusion to this painful story, I believe we owe
implementors and network administrators very clear guidelines on what to do now
and confusion in this section of the document is IMHO not acceptable.


I think the key is to dissociate in this text what implementors and what network administrator
have to do.


To the implementors:
a) don't implement SL if you are designing a new product
b) don't rush removing SL support from your current products, this can
     be done in future releases.

To network administrators:
a) don't design new networks using SL
b) don't rush redesigning your existing network using SL
however, don't expect them to work in the future as new implementations will not support SL.


If we explain it this way, maybe we can get rid of the MUST/SHOULD keywords in this section
as anyway they are inappropriate as the IETF cannot tell nor enforce what implementors
or network administrators do or don't.


- Alain.



On Dec 5, 2003, at 9:43 AM, Christian Huitema wrote:


It would actually be much simpler and less confusing to say only
"The special behavior of this prefix SHOULD no longer be supported"
and nothing about existing deployments.

This doesn't work operationally, because people use site-locals today. And as we've debated endlessly we don't do flag days anymore.

IMHO this text is good enough to ship.

I understand Alain's point, the possible confusion about what do in service packs and other types of upgrades, but we went round and round and eventually decided to just leave the text as is.

We had a very explicit discussion of this topic during the WG meeting in
Minneapolis, and the sense of the room was rather close to Eliot's
opinion. In fact, I proposed to change the text to Alain's wording, but
Brian Carpenter objected that this would cause more confusion, since we
really want to say "MUST not use" to prevent further usage, and "SHOULD"
does not achieve that. The sense of the room was clearly with Brian. I
guess this is one of the cases where the consensus is a bit rough.


-- Christian Huitema


--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to