[dhcwg] Murray Kucherawy's Discuss on draft-ietf-dhc-addr-no tification-12: (with DISCUSS and COMMENT)

Murray Kucherawy via Datatracker <[email protected]> Wed, 15 May 2024 22:13:23 -0700
Newsgroups gmane.ietf.dhc
Message-ID <[email protected]>
Murray Kucherawy has entered the following ballot position for
draft-ietf-dhc-addr-notification-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-notification/



----------------------------------------------------------------------
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 ...".


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Just checking: Are we sure exceeding the usual limit on author count is
justified here?

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.



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