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

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-v6ops-cpe-slaac-renum-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/



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

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

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.

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.

   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?

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")?

      *  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.)

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 [...]")?

      *  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)?

      *  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'.

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

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.

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