Subject: [v6ops] Roman Danyliw's No Objection on draft-ietf-v6ops-slaac-renum-04: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 20 Oct 2020 14:32:06 -0700

Roman Danyliw 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:
----------------------------------------------------------------------

Thanks to Klaas Wiereng for the SECDIR review.

** Section 6.  As Section 3.2 is proposing tuning the parameters in RFC4861, it
is likely worth reiterating that these security considerations still apply

** Editorial
-- Section 1.  Editorial. s/and and/and/

-- Section 2.2.  Most of this text was already stated in Section 1.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Oct 2020 18:57:34 -0300

Hello, Roman,

Thanks so much for your comments! In-line...

Not sure what you mean. The security considerations in RFC4861, or 
something else?

> -- Section 1.  Editorial. s/and and/and/

Thanks! Will fix this.

Thanks!

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

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 20 Oct 2020 22:07:20 +0000

Hi Fernando!

> -----Original Message-----
> From: iesg <[email-masked]> On Behalf Of Fernando Gont
> Sent: Tuesday, October 20, 2020 5:58 PM
> To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
> Cc: Owen DeLong <[email-masked]>; [email-masked]; v6ops-
> [email-masked]; [email-masked]
> Subject: Re: Roman Danyliw's No Objection on draft-ietf-v6ops-slaac-renum-04:
> (with COMMENT)
> 
> Hello, Roman,
> 
> > ** Section 6.  As Section 3.2 is proposing tuning the parameters in
> > RFC4861, it is likely worth reiterating that these security
> > considerations still apply
> 
> Not sure what you mean. The security considerations in RFC4861, or something
> else?

Yes, and this is minor, I meant to restate the obvious that RFC4861 applies (instead of a bare statement that no new security).

Regards,
Roman

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Oct 2020 20:05:11 -0300

Hello, Roman,

> Yes, and this is minor, I meant to restate the obvious that RFC4861 applies (instead of a bare statement that no new security).

Would you consider your comment addresses if we tweak the Security 
Considerations text as:

    This document discusses a problem that may arise in scenarios where
    flash-renumbering events occur, and proposes workarounds to mitigate
    the aforementioned problems.  This document does not introduce any
    new security issues, and thus the same security considerations as
    for [RFC4861] apply.

?

Thanks!

Cheers,

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 21 Oct 2020 02:10:40 +0000

Hi Fernando!

> From: Fernando Gont <[email-masked]>
> Sent: Tuesday, October 20, 2020 7:05 PM
> > Yes, and this is minor, I meant to restate the obvious that RFC4861 applies
> (instead of a bare statement that no new security).
> 
>     for [RFC4861] apply

That text looks good and would address my feedback.  Thank you!

Regards,
Roman