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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 20 Oct 2020 21:53:56 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-v6ops-cpe-slaac-renum-05: 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-cpe-slaac-renum/

----------------------------------------------------------------------
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.)

Section 2

   purpose of establishing industry-common baseline functionality.  As
   such, the document points to several other specifications (preferable
   in RFC or stable form) to provide additional guidance to implementers

I'm not sure that there's value in saying "preferable" [sic] in the
final RFC; it's not like there would be a further chance to change the
reference to have such a property anymore.

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 [...]'.
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.

   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?

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.)

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 [...]")?

      *  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)?

      *  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'.

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.)

Section 8.1

Since we say that we are *not* using the BCP 14 keywords in the sense of
RFC 2119, it does not seem that RFC 2119 needs to be a normative
reference.

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.)

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Oct 2020 03:59:28 -0300

Hello, Ben,

On 21/10/20 01:53, Benjamin Kaduk via Datatracker wrote:
[....]

FWIW, the "Intended status" in the datatracker was simply an error. -- 
the document has always targeted "Informational", since the document it 
is updating is also Informational.

My understanding is that [RFC4861] specifies a default value for some 
parameters, which are not necessarily the "recommended" values.

For the most part, this document follows the style and track of RFC7084.

> additional text in the introduction that is not appropriate for an

Will do.

> reference to have such a property anymore.

I think we should s/preferable/preferably/. That said, what the document 
means is that in these cases, other documents such as e.g. RIPE BCOPs 
might be referenced.

> paragraphs unchnaged, either.

If you think such changes would improve the document, please feel free 
to propose tweaks/text. (Thanks!)

> Is it worth mentioning that ND_PREFERRED_LIMIT and ND_VALID_LIMIT are

I wouldn't mind noting that if you think that would improve the 
document. In such case, how about adding

NOTE:
    ND_PREFERRED_LIMIT and ND_VALID_LIMIT are defined in Sectonn 4
    of this document.

?

> (nit) do we want "received" in there anywhere (e.g., "received DHCPv6-PD

Will do.

> (Likewise, we could use "received" or "WAN-side" here.)

Will do.

> "If a CE Router provides SLAAC configuration information, then [...]")?

It is assumed that all CE Routers provide SLAAC configuration 
information, since it's the only mandatory mechanism for doing so 
(DHCPv6 is optional).

> are sent in response to Solicit messages, not any of the listed ones)?

Unless I'm missing something: yes, that's deliberate. Essentially, what 
we are saying is that messages that can convey lease information should 
advertise the stale prefix as stale. (Advertise messages do not convey 
that kind of information).

> stable storage may represent a challenge for some implementations'.

Will apply the suggested edit. (Thanks!).

> draft-ietf-v6ops-slaac-renum applies, which still does not imply any

Would tweaking the last sentence of the Security Considerations as:
"It does not introduce new security issues, and therefore the security 
considerations for [RFC7084] also apply to this document."

address this?

> RFC 2119, it does not seem that RFC 2119 needs to be a normative

Fair enough. Will move RFC2119 to the Informational references.

> documents in order to have a functional setup.)

Agreed. Will do.

Thanks!

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 22 Oct 2020 09:18:42 -0700

> is updating is also Informational.

Fair enough.  That document looks like it might be better as a BCP, though
:)

Anyway, I chose to not ballot Discuss on this topic (but Alissa did), so
probably the discussion on this topic should not happen in this thread.

> to propose tweaks/text. (Thanks!)

My recommendation is for the first paragraph to change to have 'This meanas
that the "Preferred Lifetime" and "Valid Lifetime" advertised on the
LAN-side MUST be dynamically adjusted [...]', to give the two paragraphs a
(relatively) parallel structure.

>     ND_PREFERRED_LIMIT and ND_VALID_LIMIT are defined in Sectonn 4

Sounds good; thanks.

> information, since it's the only mandatory mechanism for doing so 

Okay; thanks for the reminder about SLAAC being mandatory.

> that kind of information).

Okay.  I tried to look through RFC 8415 to see whether they did, and didn't
find a clear answer in the time alloted, so I asked.

> considerations for [RFC7084] also apply to this document."

Yes; thanks.

> Fair enough. Will move RFC2119 to the Informational references.

(I guess this may become irrelevant in light of the other ballot threads.)

Thanks!

-Ben