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

On Thu, May 16, 2024 at 5:25 AM Jen Linkova <[email protected]> wrote:

> On Thu, May 16, 2024 at 3:13 PM Murray Kucherawy via Datatracker
> <[email protected]> wrote:
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > Why the SHOULD in Section 3?  This seems to me to be the key to the
> entire
> > idea, but compliant implementations have a choice not to do so?  When
> would you
> > not?
> >
> > Unless I'm reading this wrong, you probably want something like "clients
> > implementing this specification will multicast ..." or "clients
> implementing
> > this specification MUST multicast ...".
>
> We've replaced it with 'client implementing this specification
> multicasts an ADDR-REG-INFORM message'
>

Thanks, that solves the DISCUSS.


> > COMMENT:
> > ----------------------------------------------------------------------
> > Just checking: Are we sure exceeding the usual limit on author count is
> > justified here?
>
> I believe we are, and it should be documented in the shepherd's writeup.
>
> > 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?

- "If a client has the address registration mechanism enabled, it
> SHOULD include this option in all Option Request options that it
> sends." - SHOULD is replaced with MUST
>

Nice.


> - Instead of 'the server SHOULD log the registration information' the
> text is now saying 'MUST'
>

Also nice.  My colleagues from OPS in a prior IESG taught me that "SHOULD"
has slightly different meaning in operational contexts, so "SHOULD log"
worries me less these days.  :-)


> - "the client SHOULD retransmit the message' is now 'the client MUST
> retransmit the message'. This is actually consistent with RFC8415,
> which uses 'must' (not MUST though) in the retransmission section.
>

Even better!


> - the server MUST remove the binding when the address becomes invalid
> (it was 'SHOULD').
>
> I hope those changes address your DISCUSS and your comments.
>

Yep, thanks for the followup.  I'll change my ballot when this IESG meeting
ends.

-MSK

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