Re: I-D ACTION:draft-ietf-ipv6-deprecate-site-local-02.txt

[Keith Moore <moore@xxxxxxxxxx>]

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