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

Hi Murray,

Thank you very much for reviewing the document!

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'

> 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'.
Anyway, the authors have reviewed the text and made a few changes, in
line with your DISCUSS actually. The main goal is to ensure that if
both the server and the client supports the proposed protocol, it is
actually used (MUST be used, instead of SHOULD be used).
In particular:

- "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
- Instead of 'the server SHOULD log the registration information' the
text is now saying 'MUST'
- "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.
- the server MUST remove the binding when the address becomes invalid
(it was 'SHOULD').

I hope those changes address your DISCUSS and your comments.

-- 
Cheers, Jen Linkova

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