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

[Benjamin Kaduk <[e-mail]>]

On Wed, Oct 21, 2020 at 03:59:28AM -0300, Fernando Gont wrote:
> Hello, Ben,
> 
> 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.)
> 
> 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.

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.

> 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.
> 
> 
> 
> > 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.)
> 
> Will do.
> 
> 
> 
> 
> > 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.
> 
> 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.
> 
> 
> 
> > 
> > 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.
> 
> If you think such changes would improve the document, please feel free 
> 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.

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

Sounds good; thanks.

> 
> 
> > 
> > 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")?
> 
> Will do.
> 
> 
> 
> >        *  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.)
> 
> Will do.
> 
> 
> 
> > 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 [...]")?
> 
> It is assumed that all CE Routers provide SLAAC configuration 
> information, since it's the only mandatory mechanism for doing so 
> (DHCPv6 is optional).

Okay; thanks for the reminder about SLAAC being mandatory.

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

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.

> 
> 
> >        *  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'.
> 
> Will apply the suggested edit. (Thanks!).
> 
> 
> 
> > 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.)
> 
> 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?

Yes; thanks.

> 
> > 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.
> 
> Fair enough. Will move RFC2119 to the Informational references.

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

> > 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.)
> 
> Agreed. Will do.

Thanks!

-Ben