I have read the OpenTrackIO v1.0.0 web page and have a few questions.

[flow-dev]

@jamesmosys

I have read the OpenTrackIO v1.0.0 web page and have a few questions.
Could you please provide clarification on the exact specifications?

About “Source Number” in IP Addressing

There is also a “sourceNumber” parameter, and the description of both seems to be identical.
However, the range of each value is different: 1 to 200 for “Source Number” and 0 to 4,294,967,295 for “sourceNumber”.
Are these the same thing?

About the transforms parameter

Is the order of rotation of Euler angles defined as pan -> tilt -> roll?

About Packet Header parameter definition

• If the Sequence number reaches the maximum UINT16 value of 0xFFFF, does it become 0x1 in the next packet? (not 0).
• Is the unit of Segment offset in bytes?
• Is the green line in the figure the correct range for Payload Length? Also, if Payload Length is not in 4-byte units, is it necessary to padd Payload as shown in the figure and align it in 4-byte units?

[flow-dev]

@jamesmosys

The OpenTrackIO v1.0.0 specification designates the use of multicast addresses in the range 235.135.1.xxx (1–200). However, isn't this a reserved address range? If so, has OpenTrackIO officially registered this address range for use? If there are no plans to register it, I would like to request that the OpenTrackIO specification allow the use of non-reserved addresses instead. What are your thoughts on this?

https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml

[makkbe]

@flow-dev based on our research, 235.0.0.0/8 is not a reserved multicast group. It falls within the administratively scoped multicast address range (239.0.0.0/8), but 235.0.0.0/8 is actually part of the general-purpose multicast address space and is available for OpenTrackIO without registration.

[flow-dev]

@makkbe

Thank you for your reply.

It appears that RFC 5771 does not explicitly state whether the 235.0.0.0/8 range is reserved or not. For confirmation, I would greatly appreciate any reference material that clarifies this point.

Additionally, regarding OpenTrackIO, is the use of the 235.0.0.0/8 multicast address range mandatory or merely recommended?
When transmitting OpenTrackIO data, must it be sent using an address within 235.0.0.0/8, or is this just a guideline, allowing users to select other multicast addresses depending on their needs and responsibilities?

https://datatracker.ietf.org/doc/html/rfc5771

[makkbe]

@flow-dev I’m not sure what other reference material would be helpful here. Per IANA, the 235.0.0.0 to 238.255.255.255 range is not reserved for any special use, so it’s available for general use.

Personally, I would consider the use of the specified multicast address strongly recommended, if not mandatory. That said, since OpenTrackIO is not yet a formal standard, we can’t technically enforce it. The intent behind generating multicast groups based on a known prefix and a user-definable last octet is to promote interoperability and eliminate the need for end users to manage IP configurations manually. When the same source number is used on both Producers and Consumers, it should “just work.” This model of simplifying setup is well-established in the production industry and used in several ANSI standards.

The only reasonable case for deviating from the default multicast address would be if another system is already using the same group. Even then, a properly implemented OpenTrackIO receiver should be able to filter out irrelevant traffic by validating the packet structure and headers.

[flow-dev]

@makkbe
According to RFC 5771, the address range 234.0.0.0 – 238.255.255.255 (5 /8s) is designated as “RESERVED.”

https://datatracker.ietf.org/doc/html/rfc5771

I have understood “RESERVED” to mean that these address spaces are held by IANA or defined by an RFC for future use, standardization, or special-purpose allocations, and therefore should generally not be used by regular users or applications.

Based on this understanding, there seems to be a significant difference in interpretation here.

Rather than recommending addresses within the 234.0.0.0 – 238.255.255.255 range (particularly 235.0.0.0 onwards), wouldn’t it be more appropriate to refer to ranges that are clearly designated for general use according to RFC 5771 or other official documentation?

For example, perhaps we could instead consider ranges that are:
• explicitly defined for Source-Specific Multicast (e.g., 232.0.0.0/8),
• or part of the Administratively Scoped range (e.g., 239.0.0.0/8),
especially if those are already supported or recommended by projects like OpenTrackIO.

Please understand that, in environments where strict adherence to IETF and IANA specifications is required—such as in devices with rigorous security standards—this aspect must be explicitly clarified and handled.

Would love to hear your thoughts.

[makkbe]

@flow-dev I have reached out to IANA for clarification. Hopefully they will be able to get back to us within a sensible timeframe.

Thank you for your feedback and input!

[flow-dev]

@makkbe Thank you very much. I look forward to hearing from you.

[flow-dev]

@makkbe @jamesmosys

All my queries about v1.0.0 seem to have been resolved in v1.0.1, so I’ll go ahead and close this discussion.