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

[Owen DeLong <[e-mail]>]

> On May 26, 2020, at 09:18 , Philip Homburg <[e-mail]> wrote:
> 
> 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”

It’s already there… The entire document is about what the router can put into RAs
that are based on lifetimes received via DHCP-PD. If you’re hand-configuring them,
then you’re already out of the defined scope of the document.

>> "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. 

If that’s the weirdest thing you encounter in RFCs, then you lead a sheltered life.

Owen