Re: [v6ops] AD Review of draft-ietf-v6ops-slaac-renum

[Fernando Gont <[e-mail]>]

Hello, Warren,

Thanks a lot for your review! In-line....

On 10/8/20 14:17, Warren Kumari wrote:
[....]
> 
> Questions / comments:
> 1: "In scenarios where the CPE router crashes and reboots, the CPE may
> be leased (via DHCPv6-PD) a different prefix from the one previously
> leased, and therefore advertise (via SLAAC) the new prefix on the LAN
> side."
> I understand what this sentence is trying to say, but it took a few
> readings - I kept reading it that the CPE device itself may be leased,
> and then getting confused. I'm not quite sure how  to fix it, but
> does:
> "In scenarios where the CPE router crashes and reboots, the CPE may be
> obtain (via DHCPv6-PD) a different prefix from the one previously
> leased, and therefore advertise (via SLAAC) the new prefix on the LAN
> side." work?

Yes (modulo s/may be obtain/may obtain/)



> 2: "If such a push results in changing the /64 subnet configured on a
> particular network..." - I suggest dropping the "/64" - it doesn't add
> anything to the sentence is is likely to just attract controversy /
> questions.

Good point. Will do.


[I've removed grammatical issues where no further comments on my side 
were needed -- and where I will simply apply your suggested changes]

> O: If such a push results in changing the /64 subnet configured on a
> particular network, hosts attached to that network would not get
> notified about the subnet change and their addresses from the "old"
> prefix will not deprecated.
> P: If such a push results in changing the /64 subnet configured on a
> particular network, hosts attached to that network would not get
> notified about the subnet change and their addresses from the "old"
> prefix will not be deprecated.
> C: Missing "be"

Should we also remove the "/64" here?  (since you suggested that for a 
different paragraph)



> Section 2:
> O: As noted in Section 1, the problem discussed in this document
> exacerbated by a number of different parameters and behaviours.
> P: As noted in Section 1, the problem*s* discussed in this document
> are exacerbated by a number of different parameters and behaviours.
> C: I don't really like "parameters" here - perhaps "default
> parameters" or just drop it?

One option is to fix it as "... by the default values of some protocol 
parameters and other factors"?

Thanks a lot for the feedback! I will rev the doc asap.

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