[v6ops] Robert Wilton's No Objection on draft-ietf-v6ops-slaac-renum-04: (with COMMENT)

[Robert Wilton via Datatracker <[e-mail]>]

Robert Wilton has entered the following ballot position for
draft-ietf-v6ops-slaac-renum-04: 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-slaac-renum/



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

Hi,

Thank you for this document that highlights an operational issue.

My same comments regarding the acknowledgements and references as for
draft-ietf-v6ops-cpe-slaac-renum-05 also apply here.

Thank you to Juergen for the Opsdir review.   I also broadly agree with his
comments.  Although tweaking the SLAAC timers helps reduce this problem
somewhat, it doesn't seem to mitigate it altogether.  Ideally, there would be a
way for the SLAAC protocol to indicate that the advertised prefixes replace all
prefixes that had previously been advertised by that device.  Hopefully
draft-ietf-v6ops-slaac-renum will specify suitable mitigation.

I also agree with Juergen's statement regarding trying to make hosts more
robust if they detect connectivity failures, particularly if there are multiple
prefixes available that they could choose from.  I don't know if this might be
worth mentioning in section 4 on Future Work?

Regards,
Rob