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

[Warren Kumari <[e-mail]>]

Hi there authors!

Thank you for this document - it is clear, useful, and addresses a real issue...

Unfortunately there were discussions at the plenary (and then further
discussions in the IESG) on polishing the readability, etc of
documents before sending them for IETF LC / balloting, and so I've
been extra "picky" on typos, grammar, etc. I also ran it though some
automated grammer checking tools, so apologies for all the nits.

Addressing these should make the document easier to read, and so
result in better / faster review.... If I'd been a bit cleverer, I
would have just asked for the source document so that there is less
copying and pasting...

Thanks again for the document, and apologies again for all of the nits...

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?

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.




Abstract:
O: This document documents this problem, and discusses operational
workarounds that may help to improve network robustness.
P: This document documents this issue and discusses operational
workarounds that may help to improve network robustness.

Intro:
O: However, there are a number of scenarios that may lead to
P: However, there several scenarios that may lead to

O: ... nodes on the local network will continue using stale prefixes
for an unacceptably long period of time, thus...
P: ... nodes on the local network will continue using stale prefixes
for an unacceptably long time, thus...

O: Hosts will normally configure addresses for the new prefix,
P: Hosts will typically configure addresses for the new prefix,

O: In particular there has been evidence that some 802.1x
P: In particular, there has been evidence that some 802.1x

O: Automated device config management system performs periodical
config push to network devices...
P: Automated device config management system perform periodic config
pushes to network devices...

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"

O:  Lacking any explicit signaling to "deprecate" the
previously-advertised prefixes
P: Lacking any explicit signaling to deprecate the
previously-advertised prefixes
C: Unclear why deprecate is in quotes.

O: hosts may continue to employ the previously-configured addresses which
P: hosts may continue to employ the previously-configured addresses, which

O: -- whether because of egress-filtering by the CPE or ISP, or
because responses to such packets be discarded or routed elsewhere.
P: -- whether because of egress-filtering by the CPE or ISP, or
because responses to such packets are discarded or routed elsewhere.
C: or "packets being discarded or routed elsewhere."

O: ... retained and also actively employed for new communications
instances for unacceptably long period of time..
P: ... retained and also actively employed for new communications
instances for an unacceptably long period of time ...

O: However, for robustness reasons it is also paramount
P: However, for robustness reasons,  it is paramount

O: flash-renumbering events occur and the network is unable to
explicitly notify hosts about such condition.
P: flash-renumbering events occur and the network is unable to
explicitly notify hosts about such conditions.
C: plural.

O: Section 2 analysis this problem in more detail.
P: Section 2 analyzes this problem in more detail.

O: Section 4 describes possible future work to better mitigate the
aforementioned problem
P: Section 4 describes possible future work to mitigate the
aforementioned problem

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?

O: Each of the following sections analyze each of them in detail.
P: The following sections analyze each of them in detail.

C: "The authors of this document understand that, for a number of
reasons (such as the ones stated above), IPv6 deployments may employ
dynamic prefixes " - as it is now a WG / IETF document, I think that
you should remove the "The authors" bit (unless you *really* want to
keep it)

Section 2.2:
O: One common example for the use of timers is when implementing
reliability mechanisms where a packet is transmitted, and unless a
response is received, a retransmission timer will go off to trigger
retransmission of the original packet.
P: One use of timers is when implementing mechanisms where a packet is
transmitted, and, unless a response is received, a timer will fire to
trigger retransmission of the original packet.

O: For obvious reasons, the whole point of using timers is that in
problematic scenarios, they will go off, and trigger some recovery
action.
P: For obvious reasons, the whole point of using timers in this way is
that, in problematic scenarios, they trigger some recovery action.

O: However, under problematic circumstances such as where the
corresponding network
P: However, under problematic circumstances, such as where the
corresponding network

O: The Preferred Lifetime of an address can be reduced to any value to
avoid the use of a stale prefix to be employed for new communications.
P: The Preferred Lifetime of an address can be reduced to any value to
avoid using a stale prefix for new communications
or
The Preferred Lifetime of an address can be reduced to any value to
avoid the use of a stale prefix for new communications.

Section 2.4:
O: Whenever prefix information has changed, a SLAAC router should not
only advertise the new information, but should also advertise the
stale information with appropriate lifetime values (both "Preferred
Lifetime" and "Valid Lifetime" set to 0), such that there is explicit
signaling to SLAAC hosts to remove the stale information (including
configured addresses and routes).
P: Whenever prefix information has changed, a SLAAC router should not
only advertise the new information, but should also advertise the
stale information with appropriate lifetime values (both "Preferred
Lifetime" and "Valid Lifetime" set to 0), in order to provide explicit
signaling to SLAAC hosts to remove the stale information (including
configured addresses and routes).
C: Even better would be to split this into separate sentences...



Thank you again!
W



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf