[v6ops] Erik Kline's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS and COMMENT)

[Erik Kline via Datatracker <[e-mail]>]

Erik Kline has entered the following ballot position for
draft-ietf-v6ops-cpe-slaac-renum-05: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

[ section 3.2 ]

* I absolutely agree in principle at these other lifetimes should be updated
  to the shorter of the two applicable lifetimes, but I'm worried that this
  text is not sufficiently precise.  Specifically, this recommendation only
  applies to options that depend in any way on the change in the delegated
  prefix, yes?  Perhaps just this qualifier is sufficient?

  For example, none of these comparative lifetime recommendations apply to
  a stable ULA for a router that meets requirements ULA-[1..5] and chooses
  to advertise a ULA /48 RIO and maybe even a ULA DNS server, I think.

  That being said, should this document also be saying that the ULA-derived
  options SHOULD prefer the ND_{P,V}_LIMIT lifetime values, in case a reboot
  causes a new ULA to be generated (i.e. the one supposedly in stable storage
  is lost or otherwise unrecoverable)?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

[[ comments ]]

[ section 3.1 ]

* With respect to the second bullet: the lifetimes need to be dynamically
  *updateable*, not necessarily updated if, for example, the ND_{P,V}_LIMIT
  values are always lower than the remaining PD lifetimes.  In this situation,
  the requirement is still that the lifetimes can be updated, but to the
  casual observer of the steady state the RA contents might appear static
  (e.g., while the PD'd prefix is continuously renewed).

  Maybe there's no text required here, but I didn't want a reader to be left
  with the impression that no two RAs could be identical


[[ nits ]]

[ section 3.3 ]

* In the 2nd bullet's 2nd bullet (this might be easier if these lists were
  numbered), it might be good to clarify that "the *deprecated* prefix can
  simply be advertised..."