[Int-area] Re: Call for adoption: draft-giese-dhcp-rate-signaling-01 (Ends 2026-08-21)

[Christian Giese <[e-mail]>]

Thanks, Alan. I have opened an issue regarding the updates related to RFC
9445 and the IANA Registry.
https://github.com/GIC-de/draft-dhcp-rate-signaling/issues/12

On Sat, Aug 1, 2026 at 8:25 PM Richard Patterson <[e-mail]>
wrote:

> Thanks Alan and that's a good shout, will do!
>
>
> On Sat, 1 Aug 2026, 17:07 Alan DeKok, <alan.dekok=
> [e-mail]> wrote:
>
>>   I support adoption.
>>
>>   The authors may consider updating RFC 9445 and the associated IANA
>> registry "DHCP Options Permitted in the RADIUS DHCPv4-Options Attribute",
>> to allow this option to be passed in a RADIUS Access-Accept packet.
>>
>>   This configuration is the kind of thing which can be useful to send
>> from a RADIUS server to a GGSN / etc.  That way there are multiple ways
>> that bandwidth limits can be signalled.
>>
>>   Alan DeKok.
>>
>> > On Jul 31, 2026, at 10:03 AM, Carlos Jesús Bernardos via Datatracker <
>> [e-mail]> wrote:
>> >
>> > This message starts a intarea WG Call for Adoption of:
>> > draft-giese-dhcp-rate-signaling-01
>> >
>> > This Working Group Call for Adoption ends on 2026-08-21
>> >
>> > Abstract:
>> >   This document defines new Dynamic Host Configuration Protocol (DHCP)
>> >   options for both DHCPv4 and DHCPv6 to explicitly signal available
>> >   upstream and downstream data rates.  In many broadband access
>> >   networks, Customer Premises Equipment (CPE) and intermediate nodes
>> >   lack visibility into the subscriber's provisioned service tier.  By
>> >   communicating these capacities natively via DHCP, clients, relay
>> >   agents, and snooping switches can dynamically configure localized
>> >   traffic shaping and queuing.  This explicit signaling improves
>> >   overall network performance by reducing the reliance on
>> >   indiscriminate packet dropping and policing at the service edge.
>> >   Additionally, it provides the necessary capacity awareness to enable
>> >   effective Active Queue Management (AQM) and the Low Latency, Low
>> >   Loss, and Scalable Throughput (L4S) architecture.
>> >
>> > Please reply to this message and indicate whether or not you support
>> adoption
>> > of this Internet-Draft by the intarea WG. Comments to explain your
>> preference
>> > are greatly appreciated. Please reply to all recipients of this message
>> and
>> > include this message in your response.
>> >
>> > Authors, and WG participants in general, are reminded of the
>> Intellectual
>> > Property Rights (IPR) disclosure obligations described in BCP 79 [2].
>> > Appropriate IPR disclosures required for full conformance with the
>> provisions
>> > of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
>> > Sanctions available for application to violators of IETF IPR Policy can
>> be
>> > found at [3].
>> >
>> > Thank you.
>> > [1] https://datatracker.ietf.org/doc/bcp78/
>> > [2] https://datatracker.ietf.org/doc/bcp79/
>> > [3] https://datatracker.ietf.org/doc/rfc6701/
>> >
>> > The IETF datatracker status page for this Internet-Draft is:
>> > https://datatracker.ietf.org/doc/draft-giese-dhcp-rate-signaling/
>> >
>> > There is also an HTML version available at:
>> > https://www.ietf.org/archive/id/draft-giese-dhcp-rate-signaling-01.html
>> >
>> > A diff from the previous version is available at:
>> >
>> https://author-tools.ietf.org/iddiff?url2=draft-giese-dhcp-rate-signaling-01
>> >
>> > _______________________________________________
>> > Int-area mailing list -- [e-mail]
>> > To unsubscribe send an email to [e-mail]
>>
>> _______________________________________________
>> Int-area mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>