Subject: Re: [v6ops] Benjamin Kaduk's No Objection on draft-ietf-v6ops-cpe-slaac-renum-05: (with COMMENT)

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Jan 2021 18:21:30 -0300

Hi, Ben,

Just me going through IESG reviews to find if there's anything I had 
missed. Please see in-line....

On 21/10/20 01:53, Benjamin Kaduk via Datatracker wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I am not sure that we should avoid having the conversation about
> intended status; consider, for example, "CE Routers SHOULD override the
> default [...] values from [RFC4861]" (RFC 4861 is a Draft Standard).  (The
> question was raised in the genart review thread by virtue of skew between
> the datatracker state and the document header, but it looks like the WG chair
> changed the status in the datatracker and there was no further discussion of
> the topic on the list.)
> 
> The diff between Abstract and Introduction is interesting: there is a
> parenthetical "(such as when a Customer Edge Router crashes and reboots
> without knowledge of the previously-employed configuration information)"
> only in the abstract that might also be useful in the introduction, and
> the abstract uses 'hosts' where the introduction uses 'nodes'.  (There
> are a couple other incidental wording differences that the authors might
> wish to consider normalizing on one wording for, as well as the expected
> additional text in the introduction that is not appropriate for an
> abstract.)

What's the specific "text that is not appropriate for an abstract"?

> Section 3.1
> 
>                                                         This means that
>     the advertised "Preferred Lifetime" and "Valid Lifetime" MUST be
>     dynamically adjusted such that they never span past the remaining
>     preferred and valid lifetimes of the corresponding prefixes delegated
>     via DHCPv6-PD on the WAN-side.
> 
> (nitty/editorial) Perhaps it is obvious to most readers, but perhaps it
> is not universally clear that the "advertised" part refers to
> "advertised by the CPE in SLAAC PIOs"; if I wanted to reword to remove
> ambiguity, I might go with something like 'This means that the
> "Preferred Lifetime" and "Valid Lifetime" advertised in PIOs by the CE
> router MUST be dynamically adjusted [...]'.

Done.

> The next paragraph (for the DHCPv6 case) uses a similar wording, but the
> first paragraph of that sentence is a bit more clear about "employed
> with DHCPv6 on the LAN-side" that also serves to reduce the potential
> ambiguity.  I'm happy to see or propose a similar rewording for the
> DHCPv6 case if that would be useful, but don't mind if we leave both
> paragraphs unchnaged, either.

Fixed this one, too.

>     CE Routers providing stateful address configuration via DHCPv6 SHOULD
>     set the DHCPv6 IA Address Option preferred-lifetime to the lesser of
>     the remaining preferred lifetime and ND_PREFERRED_LIMIT, and the
>     valid-lifetime of the same option to the lesser of the remaining
>     valid lifetime and ND_VALID_LIMIT.
> 
> Is it worth mentioning that ND_PREFERRED_LIMIT and ND_VALID_LIMIT are
> defined in Section 4?

Done.

> Section 3.2
> 
>        *  CE Routers need not employ the (possibly long) DHCPv6-PD
>           lifetimes for the Valid Lifetime and Preferred Lifetime of PIOs
> 
> (nit) do we want "received" in there anywhere (e.g., "received DHCPv6-PD
> lifetimes")?
> 
>        *  Similarly, CE Routers need not employ the (possibly long)
>           DHCPv6-PD lifetimes for the valid-lifetime and preferred-
> 
> (Likewise, we could use "received" or "WAN-side" here.)

Applied both.

> Section 3.3
> 
>     In order to phase-out stale SLAAC configuration information:
>     [...]
>     If a CE Router provides LAN-side DHCPv6 (address assignment or prefix
>     delegation), then:
>     [...]
> 
> (editorial) Can/should these sentences use a parallel structure (e.g.,
> "If a CE Router provides SLAAC configuration information, then [...]")?

Done.

> 
>        *  In Replies to DHCPv6 Request, Renew, Rebind messages, send 0
>           lifetimes for any address assignments or prefix delegations for
>           the deprecated prefixes for at least the valid-lifetime
>           previously employed for them, or for a period of ND_VALID_LIMIT
>           if the recommended lifetimes from Section 3.2 are employed.
> 
> Is it deliberate to say nothing at all about Advertise messages (which
> are sent in response to Solicit messages, not any of the listed ones)?

I will double-check this one with my co-authors.

>        *  The requirement in this section is conveyed as a "SHOULD" (as
>           opposed to a "MUST"), since we acknowledge that the requirement
>           to store information on stable storage may represent a
>           challenge for some implementations.
> 
> (editorial/style) It's not entirely clear that we gain much from the use
> of the first person, here.  E.g., we could say 'conveyed as a "SHOULD"
> (as opposed to a "MUST"), since the requirement to store information on
> stable storage may represent a challenge for some implementations'.

Done.

> Section 6
> 
> I suggest noting that the security considerations from RFC 7084 continue
> to apply.  (Also, basically the same comment I had for
> draft-ietf-v6ops-slaac-renum applies, which still does not imply any
> changes to the text.)

Done. We've added that the security implications of rfc4861, rfc4862, 
rfc8415, and rfc7084 still apply.

> Section 8.2
> 
> It would feel more natural, at least to me, if RFC 7084 was listed as a
> normative reference.  (In the sense that we are Updating it to make
> incremental additions, but you need the whole combined assembly of both
> documents in order to have a functional setup.)

I would assume so. But it would be a downref. Is that possible?

Thanks!

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 27 Jan 2021 16:37:36 -0500

On Jan 27, 2021, at 4:21 PM, Fernando Gont <[email-masked]> wrote:
> What's the specific "text that is not appropriate for an abstract”?

The abstract should just say what topic the document covers and where it’s applicable. Anything more than that goes in the introduction. Otherwise you get these multi-paragraph abstracts that aren’t at all abstract, and don’t help the reader to decide whether or not to read the document.

Of course, usually you read the document because someone told you to, or because some other document references it, so maybe this isn’t that important… :)

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Jan 2021 19:01:50 -0300

On 27/1/21 18:37, Ted Lemon wrote:
> On Jan 27, 2021, at 4:21 PM, Fernando Gont <[email-masked] 
> <mailto:[email-masked]>> wrote:
> The abstract should just say what topic the document covers and where 
> it’s applicable.

Would this be a more concise Abstract?

This document specifies improvements to Customer Edge Routers that help 
mitigate the problems that may arise when network configuration 
information becomes invalid, without any explicit signaling of that 
condition to the affected nodes. This document updates RFC7084.

> Anything more than that goes in the introduction. 
> Otherwise you get these multi-paragraph abstracts that aren’t at all 
> abstract, and don’t help the reader to decide whether or not to read the 
> document.

I agree on that. At the same time, many times I have been asked to add 
*more* to the Abstract. :-)

> Of course, usually you read the document because someone told you to, or 
> because some other document references it, so maybe this isn’t that 
> important… :)

Agreed.

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Wed, 27 Jan 2021 17:06:34 -0500

On Jan 27, 2021, at 5:01 PM, Fernando Gont <[email-masked]> wrote:
> This document specifies improvements to Customer Edge Routers that help mitigate the problems that may arise when network configuration information becomes invalid, without any explicit signaling of that condition to the affected nodes. This document updates RFC7084.

“Stale” rather than “invalid” perhaps? But otherwise, yeah. You have budget for another sentence if you want to say more. :)

---

From: Ted Lemon <[email-masked]>
Date: Wed, 27 Jan 2021 17:06:55 -0500

Oh, you don’t need to say “updates” in the abstract because that’s in the header.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 27 Jan 2021 14:22:50 -0800

Hi Ted, Fernando,

> Of course, usually you read the document because someone told you to, or because some other document references it, so maybe this isn’t that important… :)

I agree with everything you say, though I think there may have been some
miscommunication earlier in the thread.

In particular, I was just trying to say that:
I looked at the diff between abstract and introduction, and there were some
noteworthy bits and some non-noteworthy bits.  The non-noteworthy bits are
the several extra paragrpahs in the introduction, since that's a large part
of what the difference between abstract and introduction is supposed to be.

Specifically, the "text that is not appropriate for an abstract" is
referring to text that is already (and correctly) in the introduction.  (At
least, that's what I thought when I read it the first time; I didn't look
at it right now to check.)

-Ben

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Jan 2021 19:27:02 -0300

> Oh, you don’t need to say “updates” in the abstract because that’s in 

I added that to the Abstract because I was *asked* to. You see what I 
mean? :-)

---

From: Ted Lemon <[email-masked]>
Date: Wed, 27 Jan 2021 17:32:57 -0500

On Jan 27, 2021, at 5:27 PM, Fernando Gont <[email-masked]> wrote:
> I added that to the Abstract because I was *asked* to. You see what I mean? :-)

Huh. Well, it’s mostly harmless, so I wouldn’t waste any time trying to resolve this—just leave it in. But I don’t think it’s a best practice to do this, so next time it comes up I’d be tempted to argue the point.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Jan 2021 19:49:01 -0300

Hi, Ben,

On 27/1/21 18:21, Fernando Gont wrote:
[....]
> I will double-check this one with my co-authors.

Our plan is to add this note to the RATIONALE of Section 3.3:

    The above text does not include responses to DHCPv6 Solicit messages,
    since Section 18.3.9 of RFC8415 requires that a DHCPv6 server
    that is not going to assign an address or delegated prefix received
    as a hint in the Solicit message MUST NOT include that address or
    delegated prefix in the Advertise message. Additionally, any
    subsequent Solicit messages will trigger the response specified in
    this section, and therefore cause the address or prefix to be
    deprecated.

Would this address your comment?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Jan 2021 19:51:46 -0300

On 27/1/21 19:22, Benjamin Kaduk wrote:
[...]
> at it right now to check.)

How about this for the Abstract:

.. at the end of the day, that's what the document is about.

(Note: I wouldn't have added the "This document updates RFC7084", but 
have been asked to. But won't argue about it either way :-) )

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 27 Jan 2021 23:19:43 +0000

Ted Lemon wrote on 27/01/2021 22:32:
> Huh. Well, it’s mostly harmless, so I wouldn’t waste any time trying to 
> resolve this—just leave it in. But I don’t think it’s a best practice to 
> do this, so next time it comes up I’d be tempted to argue the point.

as a general observation unrelated both to this draft and to this 
suggestion, at this stage of the ID process, it's often easier to update 
drafts with reviewers' suggestions even if authors don't feel that the 
suggestions are useful or particularly appropriate.

This is a human nature thing: you just want the draft off your to-do 
list and anything which slows this up, like minor quibbles, are easiest 
to deal with by just agreeing with a silent "meh, whatevs".

This also isn't a criticism of reviewers, whose thankless but critically 
important job is usually done to a very high standard, and is made more 
difficult by having to review content in areas which aren't necessarily 
their specialty.

I don't have a solution to this, but it's worth noting that it happens.

Nick

---

From: Brian Carpenter <[email-masked]>
Date: Thu, 28 Jan 2021 13:43:01 +1300

Mentioning Updated & Obsoleted RFCs in the Abstract has been standard
practice for years now. I believe the logic was that although redundant the
warning increases the odds that people will take note.

Regards
    Brian
    (via tiny screen & keyboard)

On Thu, 28 Jan 2021, 11:28 Fernando Gont, <[email-masked]> wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 28 Jan 2021 01:15:05 +0000

See comments below (BV>).

- Bernie (from iPad)

> On Jan 27, 2021, at 5:53 PM, Fernando Gont <[email-masked]> wrote:
> 
> Hi, Ben,
> 
BV> A Solicit with Rapid Commit may return a Reply. So this only applies to Advertise responses.
>   subsequent Solicit messages will trigger the response specified in
BV> There are usually no “subsequent” Solicits. There is a subsequent Request.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Jan 2021 22:32:54 -0300

> BV> A Solicit with Rapid Commit may return a Reply. So this only applies to Advertise responses.

Will fix this. Thanks!

> BV> There are usually no “subsequent” Solicits. There is a subsequent Request.

Oops. That was just me both sloppy and sleepy..

The resulting text is:
    The above text does not include DHCPv6 Advertise messages sent in
    response to DHCPv6 Solicit messages, since Section 18.3.9 of
    [RFC8415] requires that a DHCPv6 server
    that is not going to assign an address or delegated prefix received
    as a hint in the Solicit message MUST NOT include that address or
    delegated prefix in the Advertise message. Additionally, any
    subsequent Request messages will trigger the response specified in
    this section, and therefore cause the address or prefix to be
    deprecated.

Thanks,

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 27 Jan 2021 22:33:54 -0800

Hi Fernando,

Assuming you're interested in my opinion...

> .. at the end of the day, that's what the document is about.

That looks pretty solid; thanks for iterating to get to it.

> have been asked to. But won't argue about it either way :-) )

I think Brian covered this part, though I think it is just something I
assimilated as institutional knowledge and I can't point to a reference for
it.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 27 Jan 2021 22:38:19 -0800

Hi Fernando,

> What's the specific "text that is not appropriate for an abstract"?

(As covered downthread, "the stuff that's in the introduction and not
present in the abstract", i.e., is present in the diff but is not
noteworthy.)

[...]
> I would assume so. But it would be a downref. Is that possible?

Most things are possible ... but with 7084 not listed at
https://datatracker.ietf.org/doc/downref/ it might mean another IETF LC.
Your responsible AD should probably be the one to make the call, and the
"don't change it" option has a fair bit of inertia going for it.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 27 Jan 2021 22:54:44 -0800

Hi Fernando,

>     this section, and therefore cause the address or prefix to be

This definitely addresses my comment, thanks.
Seeing it written out like that does make it seem like it would be a fine
choice to deliberately decide to not say anything about Advertise messages,
since the correct behavior is already required by the combination of what
we do say and the existing specs.  So, please do what you feel is right in
terms of adding this paragraph or leaving it out.

Thank you for working through it with me (and thanks Bernie for helping
out, too)!

-Ben

---

From: Fernando Gont <[email-masked]>
Date: Thu, 28 Jan 2021 04:44:49 -0300

> Assuming you're interested in my opinion...

I am, indeed :-)  Your reviews do make a difference in helping improve 
the quality of documents! (not just this one!)

[....]
> That looks pretty solid; thanks for iterating to get to it.

Done!

> assimilated as institutional knowledge and I can't point to a reference for

I'm not sure if this would serve as the reference that you wanted, but I 
just found this one: 
https://www.ietf.org/chairs/document-writeups/document-writeup-working-group-documents/

Item 16) seems to ask for it, or explain why that's not the case. :-)

So even if just for that, I'd add it, and save some electrons :-)

---

From: Fernando Gont <[email-masked]>
Date: Thu, 28 Jan 2021 04:49:04 -0300

On 28/1/21 03:54, Benjamin Kaduk wrote:
[...]
> terms of adding this paragraph or leaving it out.

We can add it to the RATIONALE in that section. If you had that 
question, a reader of our document could possibly also have it. So it 
could be of help.

> Thank you for working through it with me (and thanks Bernie for helping

Thank you!

Regards,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 28 Jan 2021 04:50:30 -0300

On 28/1/21 03:38, Benjamin Kaduk wrote:
[...]

Agreed.

Thanks!

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 28 Jan 2021 09:21:06 +0000

On Wed, 2021-01-27 at 17:32 -0500, Ted Lemon wrote:
> resolve this—just leave it in. But I don’t think it’s a best practice to do
> this, so next time it comes up I’d be tempted to argue the point.
> 

So having updates in abstract and in the other places is according to the
Internet Draft checklist:

https://www.ietf.org/standards/ids/checklist/

See section 3.

Cheers

Magnus Westerlund