Keith Moore wrote:
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 application implementors:
a) avoid using SL addresses in applications that exchange addresses b) don't special-case handling of SL addresses in other kinds of apps
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.
c) don't expect future apps to work with SL
to IETF and other standards organizations:
a) don't utilize SL in any future standards
I certainly agree with all those do's and don'ts and have no problem
with adding them as informative text. But we are writing a normative
document here, to update existing normative documents, so is there really
a problem with using normative words?
It's often seemed to me like a significant part - probably the most significant part - of what it means to "deprecate" SL consists of things which are probably better stated in non-normative language, because the normative language is both too inflexible and too divisive. If section 4 were to start with a non-normative explanation of what it means to deprecate SL, and then supply normative language for those parts where it makes sense, I think the picture would be clearer.
Which software release counts as "new" is indeed not a question for
the IETF, and each implementer will have to make his/her own judgement
about exactly when to remove the feature. But I don't think it's wrong to
say that they MUST remove it.
Well, it does beg the question of how to say whether a particular implementation is in conformance. Many people feel that a MUST requirement should be testable, but a MUST requirement that exists at some undefined time in the future is not testable.
Personally I don't have a problem with this document saying MUST (provided the non-normative text is also there), but I think the text that says that future revisions of other specs will not support SL might be more important.
Keith
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
