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

[Fernando Gont <[e-mail]>]

On 22/5/20 12:46, Philip Homburg wrote:
>> In that case, how would the new CPE get its packets, anyway? I don't
>> seem to see what you'd be "fixing" by manually extending the lifetimes.
> 
> I'm assume that there are and will be plenty of cases where hosts use
> the public prefix to communicate internally, certainly if the customer
> has a static prefix.

If the prefix is static, I wonder why you'd use DHCPv6. That said, a 
static prefix would be, I guess, a prefix with an infinite lifetime. So, 
if anything, one might consider this value as a special case -- i..e, if 
the DHCPv6 valid-lifetime is infinity (0xffffffff), set the RA lifetime 
to infinity.




>> The recommendations in this document have to do with what the CE Router
>> does, by default, without human intervention.
>>
>> We're not precluding CE Routers to have other knobs to do other things.
>>
>> So I fail to see why you say L-15 should be "relaxed". -- L-15 is not
>> arguing that you should or should not manually configure stuff in your
>> CE Router.
> 
> I assume that when RFC 2119 says about MUST NOT: 'This phrase, or the
> phrase "SHALL NOT", mean that the definition is an absolute prohibition
> of the specification.' it includes overrides by the user.
> 
> In particular when SHOULD NOT says: 'This phrase, or the phrase "NOT
> RECOMMENDED" mean that there may exist valid reasons in particular
> circumstances when the particular behavior is acceptable or even useful,
> but the full implications should be understood and the case carefully
> weighed before implementing any behavior described with this label.'
> 
> But maybe my interpretation is wrong.
> 
> BTW, I noticed that the draft does not have the boilerplate text that
> refers to RFC 2119.

That is indeed a good point. Maybe we should copy the terminology 
section from RFC7084, which describes the usage of these terms in this 
document? Namely:

---- cut here ----
X.Y.  Requirements Language

    Take careful note: Unlike other IETF documents, the key words "MUST",
    "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
    "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as
    described in RFC 2119 [RFC2119].  This document uses these keywords
    not strictly for the purpose of interoperability, but rather for the
    purpose of establishing industry-common baseline functionality.  As
    such, the document points to several other specifications (preferable
    in RFC or stable form) to provide additional guidance to implementers
    regarding any protocol implementation required to produce a
    successful CE router that interoperates successfully with a
    particular subset of currently deploying and planned common IPv6
    access networks.
---- cut here ----

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492