RDMnet and E1.37-2
 

Hi All,
We are in the process of implementing RDMnet in some of our products and I have a couple of questions regarding the E1.37-2 standard and its implementation.

1) 4.8 Apply Interface Configuration (INTERFACE_APPLY_CONFIGURATION)
This command is sent when there is a Set DHCP, Set Static IP or Set Zero Config required. It is possible to send each one of these commands prior to executing this command. Thus it is possible that there will be three conflicting commands to be executed once the Apply command is received.
Which command wins or should the procedure of Section 3.5 dictate it?

2) As far as I can see E1.33 requires that all of E1.37-2 is implemented even in LLRP. There are a number of DNS commands including Host Name and Domain Name that make no sense in the product we are implementing E1.33 in as the product has no need of them and memory is a constraint.
In such a case, is it acceptable not to implement these commands and if so, what is the appropriate response - RdmNack_ActionNotSupported ?

Thanks for you help and input.

Gary, many of the people involved in writing the E1.37-2 document are at the ESTA CPWG standards meetings and Plugfest in Dallas right now, and your question kicked off an interesting discussion.

Then intent of INTERFACE_APPLY_CONFIGURATION is for it to act like the "Apply" button on an operating system. You can make as many changes as you want to the "Configured" values, but none of them will take effect until you send the APPLY PID.

(Edited to remove a mistake that was here previously)

I talked to several people who've implemented E1.37-2, and they said they ignore the priority list in section 3.5 and treat it as "last-action", so they use which mode was configured most recently (Static, DHCP, or ZeroConf).

> In such a case, is it acceptable not to implement these
> commands and if so, what is the appropriate response

You do not have to implement all of the PIDs. You can omit support for PIDs like DNS_HOSTNAME. Make sure those PIDs aren't included in your list of SUPPORTED_PARAMETERS, and NACK with NR_UNKNOWN_PID.

Thanks Eric for the explanation. It might be worth noting for future revisions of the standard to make it clear what should happen in the case I described.
Given the consensus seems to be LTP then that is what we will implement.

BTW I will be at the PlugFest in Europe next March.