[dhcwg] Re: Murray Kucherawy's Discuss on draft-ietf-dhc-a ddr-notification-12: (with DISCUSS and COMMENT)

On Fri, May 17, 2024 at 12:12 AM Murray S. Kucherawy
<[email protected]> wrote:
>> > I found the majority of the SHOULD [NOT] instances in here to be unsupported.
>> > Why aren't they MUSTs?  Do they need to be SHOULD [NOT]?  What's the impact if
>> > I deviate?  What advice can we offer to implementers when confronted with these
>> > choices?  I note that a couple of the other IESG members had similar questions
>> > in a few cases.
>>
>> Interesting. I think 'MUST's need to be justified (what would be
>> broken if that MUST/MUST NOT) is violated), while SHOULD means 'it's
>> your default behaviour, so please just do it until you can explain
>> your reasons not to'.
>
>
> I use SHOULD more like "Not doing this is still compliant, but it will degrade the service this protocol provides in an important way.  You need to know what you're doing, and to make sure you do, here's the information you need to make an informed decision."  Sometimes that additional context is totally obvious from the text before it, but when it's not, I tend to poke at it.

> So for example, from your Section 4.2.1:
>
> "* SHOULD register a binding between the provided Client Identifier and IPv6 address in its database, if no binding exists."
>
> What happens if I don't do this?

This one is a good example. It illustrates that SHOULD allows us to
have implementations of various levels of functionality, and even
light-weight implementations providing minimal functionality can still
be compliant.
For example, in a SLAAC only network I might have a very light-weigh
DHCPv6 server which doesn't actually do any address assignment, so it
doesn't have any leases/bindings and is only used to log address
registration messages from clients.
This "SHOULD" allows such implementation to be  compliant.

--
Cheers, Jen Linkova

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