Re: [v6ops] Benjamin Kaduk's No Objection on draft-ietf-v6ops-cpe-slaac-renum-05: (with COMMENT)

[Fernando Gont <[e-mail]>]

Hello, Ben,

On 21/10/20 01:53, Benjamin Kaduk via Datatracker wrote:
[....]
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I am not sure that we should avoid having the conversation about
> intended status; consider, for example, "CE Routers SHOULD override the
> default [...] values from [RFC4861]" (RFC 4861 is a Draft Standard).  (The
> question was raised in the genart review thread by virtue of skew between
> the datatracker state and the document header, but it looks like the WG chair
> changed the status in the datatracker and there was no further discussion of
> the topic on the list.)

FWIW, the "Intended status" in the datatracker was simply an error. -- 
the document has always targeted "Informational", since the document it 
is updating is also Informational.

My understanding is that [RFC4861] specifies a default value for some 
parameters, which are not necessarily the "recommended" values.

For the most part, this document follows the style and track of RFC7084.



> The diff between Abstract and Introduction is interesting: there is a
> parenthetical "(such as when a Customer Edge Router crashes and reboots
> without knowledge of the previously-employed configuration information)"
> only in the abstract that might also be useful in the introduction, and
> the abstract uses 'hosts' where the introduction uses 'nodes'.  (There
> are a couple other incidental wording differences that the authors might
> wish to consider normalizing on one wording for, as well as the expected
> additional text in the introduction that is not appropriate for an
> abstract.)

Will do.




> Section 2
> 
>     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
> 
> I'm not sure that there's value in saying "preferable" [sic] in the
> final RFC; it's not like there would be a further chance to change the
> reference to have such a property anymore.

I think we should s/preferable/preferably/. That said, what the document 
means is that in these cases, other documents such as e.g. RIPE BCOPs 
might be referenced.



> 
> Section 3.1
> 
>                                                         This means that
>     the advertised "Preferred Lifetime" and "Valid Lifetime" MUST be
>     dynamically adjusted such that they never span past the remaining
>     preferred and valid lifetimes of the corresponding prefixes delegated
>     via DHCPv6-PD on the WAN-side.
> 
> (nitty/editorial) Perhaps it is obvious to most readers, but perhaps it
> is not universally clear that the "advertised" part refers to
> "advertised by the CPE in SLAAC PIOs"; if I wanted to reword to remove
> ambiguity, I might go with something like 'This means that the
> "Preferred Lifetime" and "Valid Lifetime" advertised in PIOs by the CE
> router MUST be dynamically adjusted [...]'.
> The next paragraph (for the DHCPv6 case) uses a similar wording, but the
> first paragraph of that sentence is a bit more clear about "employed
> with DHCPv6 on the LAN-side" that also serves to reduce the potential
> ambiguity.  I'm happy to see or propose a similar rewording for the
> DHCPv6 case if that would be useful, but don't mind if we leave both
> paragraphs unchnaged, either.

If you think such changes would improve the document, please feel free 
to propose tweaks/text. (Thanks!)



>     CE Routers providing stateful address configuration via DHCPv6 SHOULD
>     set the DHCPv6 IA Address Option preferred-lifetime to the lesser of
>     the remaining preferred lifetime and ND_PREFERRED_LIMIT, and the
>     valid-lifetime of the same option to the lesser of the remaining
>     valid lifetime and ND_VALID_LIMIT.
> 
> Is it worth mentioning that ND_PREFERRED_LIMIT and ND_VALID_LIMIT are
> defined in Section 4?

I wouldn't mind noting that if you think that would improve the 
document. In such case, how about adding

NOTE:
    ND_PREFERRED_LIMIT and ND_VALID_LIMIT are defined in Sectonn 4
    of this document.


?



> 
> Section 3.2
> 
>        *  CE Routers need not employ the (possibly long) DHCPv6-PD
>           lifetimes for the Valid Lifetime and Preferred Lifetime of PIOs
> 
> (nit) do we want "received" in there anywhere (e.g., "received DHCPv6-PD
> lifetimes")?

Will do.



>        *  Similarly, CE Routers need not employ the (possibly long)
>           DHCPv6-PD lifetimes for the valid-lifetime and preferred-
> 
> (Likewise, we could use "received" or "WAN-side" here.)

Will do.



> Section 3.3
> 
>     In order to phase-out stale SLAAC configuration information:
>     [...]
>     If a CE Router provides LAN-side DHCPv6 (address assignment or prefix
>     delegation), then:
>     [...]
> 
> (editorial) Can/should these sentences use a parallel structure (e.g.,
> "If a CE Router provides SLAAC configuration information, then [...]")?

It is assumed that all CE Routers provide SLAAC configuration 
information, since it's the only mandatory mechanism for doing so 
(DHCPv6 is optional).



>        *  In Replies to DHCPv6 Request, Renew, Rebind messages, send 0
>           lifetimes for any address assignments or prefix delegations for
>           the deprecated prefixes for at least the valid-lifetime
>           previously employed for them, or for a period of ND_VALID_LIMIT
>           if the recommended lifetimes from Section 3.2 are employed.
> 
> Is it deliberate to say nothing at all about Advertise messages (which
> are sent in response to Solicit messages, not any of the listed ones)?

Unless I'm missing something: yes, that's deliberate. Essentially, what 
we are saying is that messages that can convey lease information should 
advertise the stale prefix as stale. (Advertise messages do not convey 
that kind of information).



>        *  The requirement in this section is conveyed as a "SHOULD" (as
>           opposed to a "MUST"), since we acknowledge that the requirement
>           to store information on stable storage may represent a
>           challenge for some implementations.
> 
> (editorial/style) It's not entirely clear that we gain much from the use
> of the first person, here.  E.g., we could say 'conveyed as a "SHOULD"
> (as opposed to a "MUST"), since the requirement to store information on
> stable storage may represent a challenge for some implementations'.

Will apply the suggested edit. (Thanks!).



> Section 6
> 
> I suggest noting that the security considerations from RFC 7084 continue
> to apply.  (Also, basically the same comment I had for
> draft-ietf-v6ops-slaac-renum applies, which still does not imply any
> changes to the text.)

Would tweaking the last sentence of the Security Considerations as:
"It does not introduce new security issues, and therefore the security 
considerations for [RFC7084] also apply to this document."

address this?




> Section 8.1
> 
> Since we say that we are *not* using the BCP 14 keywords in the sense of
> RFC 2119, it does not seem that RFC 2119 needs to be a normative
> reference.

Fair enough. Will move RFC2119 to the Informational references.




> Section 8.2
> 
> It would feel more natural, at least to me, if RFC 7084 was listed as a
> normative reference.  (In the sense that we are Updating it to make
> incremental additions, but you need the whole combined assembly of both
> documents in order to have a functional setup.)

Agreed. Will do.

Thanks!

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