Wednesday, February 25, 2026 | 09:50am
| Attachment | Size |
|---|---|
| 3.3.2.2 - Persistent Conflict.docx | 17.22 KB |
Please Sign in to View
Log in to view member-only content.
If you believe you are receiving this message in error contact us at memberservices@rvia.org.
Jennifer Tyler Member for 3 months 4 weeks
OBJECTION:
There is a typo in the new section. In the line: "The SPN shall be the Standard SPN 14 - Node Source Address." The correct SPN is the new one proposed = 17.
Furthermore, from my software team: It seems acceptable to keep the "give up" process optional, but it's better to set a specific time to it, to avoid misunderstandings. Example: "Optionally, after 10 seconds, the device can determine that the conflict is not otherwise resolving, and may abandon the address and enter in the dynamic claiming process, targeting a new address, on its own initiative."
Martin Perlot Member for 6 months
Good catch on the typo. I blame the WRV-C team for grabbing 14, 15 and 16 before we finished drafting this submission. Those guys are out of control.
But I'm not sure about the 10-second rule. While adding a specific time might clarify things, it might also rule out other legitimate and safe alternatives. It implies that if that 10 second window passes, the device is stuck forever - but do we really want to write that in? A developer might want to use some other trigger, such as detecting any address-targeted DGN (e.g. GENERAL_RESET) to or from the address.
(Personally, I think this is the ideal. By giving up the address prematurely, you are allowing the problem to remain undetected, which is not good considering the fault is likely due to a misconfiguration and thus the device is sure to have other problems. But there is real danger in parsing address-specific messages not intended for your device! However, my ideal solution is perhaps a bit more complicated than the problem really deserves.)
The other scenario - one that unfortunately I've seen vendors forced to implement - happens when one vendor is aware that another vendor's products are buggy. I have seen the following (pseudo-)code:
if ( ( my_priority < your_priority ) OR (your_mfg_id == ACME_CORP ) ) abandon_the_address();
It we put in a specific time, we'd be eliminating the ability to insert workarounds like this. It's sad - as much as I hate seeing this sort of thing in any code, the reality is that sometimes there is no better way.
Jennifer Tyler Member for 3 months 4 weeks
Would this be better? "Optionally, after determining that the conflict is not otherwise resolving, through an attempts timeout, number of retries, or other defined conditional, a device may abandon the address and enter the dynamic claiming process, targeting a new address, on its own initiative."