Re: WGLC for draft-ietf-dhc-rfc8415bis / clarification of significant prefix change

Reviving an unanswered thread. See my responses below.

On 20.11.2023 12:46, Esko Dijk wrote:
> Agree that adding informational references would be very helpful. In
> particular, one to RFC 8987, made from a section about Relays. (This one
> I mentioned in my 1^st WGLC comment.) Others mentioned DNA (RFC 6059).
Thanks for the pointers. In the upcoming -04 we will add references to
RFC8987, RFC6059, and RFC4957. If you want to take a look before it's
published, the changes are on github:

https://github.com/dhcwg/rfc8415bis/pull/8/files

> From the SNAC WG there’s currently no suitable document to reference, I
> believe. (I.e. not one that helps to clarify the requirements.)
Noted.

> If we change text to clarify something, without proposing new
> functionality, would that still fit in the 8415bis scope or cleaning up,
> or not?
Sure. While I agree with what others had said that we should not change
normative language (so no changes for your proposals 1, 4, or 5), I'm in
favor of clarifying the text.

This effectively leaves us with items 2 (clarify when to send confirm,
renew or inf-request) and 3 (clarify significant change).

For item 2, my understanding is this:

If prefix was obtained, you need RENEW.
Else, if address was obtained, use CONFIRM.
Else, if only other params were obtained, use INF-REQUEST.

Or even more briefly: use CONFIRM or INF-REQUEST if you can, use RENEW
if you can't.

The rationale for this is simple. CONFIRM processing on the server side
is very lightweight (just reading the DB and send yes/no status), the
RENEW is not (it requires write to a DB, so is more costly). As such,
the general preference is CONFIRM whenever you can. Sadly, CONFIRM is
for addresses only, not for prefixes. So if you have any prefixes, you
need to go through the full hassle of RENEW. INF-REQUEST is also "cheap"
as it doesn't require DB update.

Do you have any text in mind here?

For item 3, the text you proposed on Nov 11 looks good to me. I've
applied it here: https://github.com/dhcwg/rfc8415bis/pull/9

> If yes then adding new examples that fall completely within the scope of
> existing functionality, should be okay as well – as long as there is
> consensus that the new example indeed complies with existing functionality.
We hope to get everything right this time. That's we said the last time :)

More seriously, though, it's OK if you want to update the list in
18.2.12. The intention was to give people some example what kind of
events could be an indication for link change. The list was never meant
to be complete. Maybe adding "Non-exhaustive" somewhere in the text
would clarify that other cases may indicate moving to a new link?

Anyway, would you be willing to donate some text for/around the examples
list update?

Thanks,
Tomek

_______________________________________________
dhcwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dhcwg