Re: [v6ops] draft-ietf-v6ops-slaac-renum and draft-ietf-v6ops-cpe-slaac-renum

[Philip Homburg <[e-mail]>]

In your letter dated Mon, 25 May 2020 13:49:30 -0300 you wrote:
>> Yes, but it introduces extra complexity. In particular, the CPE has to
>> continue to request a prefix using DHCPv6. Then a naive implementation may
>> end up with two entries for the same prefix in a single RA. Finally, the
>> implementor may realize that filtering out the prefix from DHCPv6 may
>> actually cause the CPE to violate a MUST NOT, so a strict interpretation of
>> the CPE may cause the CPE to remove the user supplied prefix.
>
>Again: this document specifies a recommended behavior when the CE Router 
>handles the whole thing automatically. You don't even need permission to 
>have a manual knob that allows you to do something else.

If there is consensus that manual configuration does not violate the 
MUST NOT, then why not write something to the effect of: "this does not
affect lifetimes explicitly configured by the operator of the CPE"

>"This document specifies recommendations for the default behavior of CE 
>Routers, and does not preclude the availability of configuration knobs 
>that might allow an operator or user to manually-configure the CE Router 
>to deviate from these recommendations"
>
>Thoughts?

I prefer adding that next to the MUST NOT, however, it does work for me
as well.

I think that MUST NOT should be reserved for cases where there are no
exceptions to the required behavior. So a blanked statement that manually
configuration can always override a MUST NOT strikes me as weird.