[dhcwg] Re: Actions after the IETF last call of draft-ietf-d hc-rfc8415bis-07

Jim Reid <[email protected]> Mon, 3 Feb 2025 14:45:43 +0000
Newsgroups gmane.ietf.dhc
Message-ID <[email protected]>
Thanks for your very extensive comments on my review of this ID Michael. I think you might have over-reacted. :-)

I looked at this doc from the PoV of a naive observer who hasn't followed the WG discussions and isn't aware of the backstory. [Which may or may not be a Good Thing.] Most of my remarks reflect this. They're mostly about what Bernie calls stylistic issues. I'm not someone who could (or should) get into the protocol detail apart from the I-D's teeny amount of DNS-related content.

> On 3 Feb 2025, at 10:38, Michael Richardson <[email protected]> wrote:
> 
> The RFC editor already kicked that can when they did RFC8415.
> We are aiming for Internet Standard:
>   https://author-tools.ietf.org/diff?doc_1=RFC8415&doc_2=draft-ietf-dhc-rfc8415bis-07&iddiff=1
> 
> Basically I'm reluctang to change too much text, because I think they might
> just want to change it back.

Please yourself. I don't have a dog in this fight. :-) Feel free to use/ignore my comments as you and your co-authors see fit. I'm not bothered either way and won't be playing in your github sandpit. Whatever turns out to be the path of least resistance for you will be fine. BTW if the doc comes back to dnsdir, another stuckeee will get picked to review it.

>    jr> My biggest gripe is the section on rate-limiting. I do not understand
>    jr> why relay- and server-side rate limiting could be deemed out of
>    jr> scope. That seems to me to be every bit as important as client-side
> 
> Mostly, DHCPv6 servers (more than DHCPv4) only reply to queries from clients.
> Clients manage retransmissions, with a few things like RECONFIGURE being
> server initiated.  (often not used, not supported...)
> So I'm not sure that there is much that servers can do to further limit
> rates, except I guess they can drop requests from annoying clients.


I was approaching this from a different perspective: servers or relays swamping the client with "too many" responses. Perhaps the doc should say something about that. Some text about dropping or ignoring requests from annoying clients seems appropriate IMO. YMMV. And is it worth considering the unlikely scenario where a single client request provokes a server or relay into zillions of (spurious?) responses?

_______________________________________________
dhcwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]