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

[Esko Dijk <[e-mail]>]

Hello Tomek,

Thanks for the response and updates. I added comments to the PRs.

> items 2 (clarify when to send confirm, renew or inf-request)
> ...
> Do you have any text in mind here?
Not yet - but I can make a proposal next week?

> Maybe adding "Non-exhaustive" somewhere in the text would clarify that other cases may indicate moving to a new link?
It looks already clear that the examples in the list are just examples! So adding more words does not seem necessary.

> Anyway, would you be willing to donate some text for/around the examples list update?
I've proposed one extra example in the PR. (Network interface indicates a disconnection event followed by a connection event)

One additional question came up while reading 18.2.12: there is the sentence

    If not associated with one of the above-mentioned conditions, ...

Which seems to complicate the mental parsing of the requirement. (Reader may wonder which conditions are meant? Is "client has only obtained network information using Information-request/Reply message exchanges" a condition, or not?)
Maybe it could be simplified as:

    If not associated with a detection of having moved to a new link, ...

This looks ok because all conditions in 18.2.12 up to that point are effectively incorporating that the client's "may have moved to a new link" detection was triggered.

Esko

-----Original Message-----
From: Tomek Mrugalski <[e-mail]> 
Sent: Wednesday, January 24, 2024 12:33
To: Esko Dijk <[e-mail]>
Cc: [e-mail]
Subject: Re: [dhcwg] 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