Re: [dhcwg] Barry Leiba's No Objection on draft-ietf-dhc-dhcpv6-pd-relay-requirements-04: (with COMMENT)

[Barry Leiba <[e-mail]>]

Indeed: there's been a minor effort to bring forth new "update"-like
things to make the distinctions among the different meanings we've
been using, but that hasn't (yet?) gotten anywhere.

The point, though, is that "updates" is the only mechanism we have to
create a forward reference in an old RFC (in the metadata) to a new
RFC, in cases where we really want people who read the old one to see
the new one.  In this case, we're not changing any text in the old
RFC, but we *are* adding interoperability requirements.  It's my sense
as I read this draft that we *do* want people who read 8415 to pay
attention to what's here, and not just go off and implement without
considering these new requirements.  So I think we should consider
"updates" in that light.

Anyway, note that neither my comment nor Roman's is at DISCUSS level.
The issue has been raised, and we trust the authors, working group,
and responsible AD to do the right thing.

Barry

On Wed, Dec 16, 2020 at 5:11 PM Bernie Volz (volz) <[e-mail]> wrote:
>
> > I was going to suggest that this should “update” 8415, and then I saw Roman’s comment.  So, yes: it really seems that this should update 8415, if, indeed, this adds interoperability requirements to an aspect of what 8415 defines.
>
> This was discussed some as at one time it had this in the header.
>
> This may be a limitation of what keywords are available and how they are interpreted. But there is nothing in this document that actually updates anything in 8415 (i.e., change this or extend that)?
>
> If there was something, one would expect to see some specific references to say things like replace this text with that or add this text to that in Section X of RFC8415? There is none of that.
>
> G-1 is a already clear in RFC8415.
> G-2 / G-3 are already clear in RFC8415 that multiple prefixes are normal and to be expected.
> G-4 is also expected as this was one reason DUIDs are unique to the client and not to an interface.
> G-5 / G-6 / G-7 are an implementation requirement independent of the DHCP.
> G-8 is already specified in RFC8415 that the lifetimes used must not exceed remaining.
> G-9 should already be clear as RFC8415 states that the "lease" must not be in used when Released.
>
> R-* are routing issues having nothing to with DHCP.
>
> S-* are not directly associated with RFC8415. They do reference leasequery documents, so would we also say that this updates those RFCs?
>
> O-* are operation issues and no protocol related.
>
>
> We also have to be careful not to use update to lightly as then it really has little meaning?
>
> - Bernie
>
>
> -----Original Message-----
> From: Barry Leiba via Datatracker <[e-mail]>
> Sent: Wednesday, December 16, 2020 4:51 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; Bernie Volz (volz) <[e-mail]>; Bernie Volz (volz) <[e-mail]>
> Subject: Barry Leiba's No Objection on draft-ietf-dhc-dhcpv6-pd-relay-requirements-04: (with COMMENT)
>
> Barry Leiba has entered the following ballot position for
> draft-ietf-dhc-dhcpv6-pd-relay-requirements-04: 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-dhc-dhcpv6-pd-relay-requirements/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I was going to suggest that this should “update” 8415, and then I saw Roman’s comment.  So, yes: it really seems that this should update 8415, if, indeed, this adds interoperability requirements to an aspect of what 8415 defines.
>
>
>