LSID: Possible future encoding optimization

[abierman]

This issue is for future work. No changes to current documents are proposed.

Problem:

Using 8 bytes of memory to store each SID has a negative impact on deployment on constrained platforms. Memory costs are also important considerations in unconstrained devices. I am concerned that IoT implementations will use uint32 and just assume the SID values will always fit in 32 bits "for the modules we need". This is a bad design approach that should be discouraged.

Solution:

A Localized SID (LSID) is an unsigned integer that maps to a specific SID. LSID.16 uses a uint16 mapping (64K) and LSID.32 uses 31 bits of a uint32 .(2G). Delta SID calculation is still done with a uint64 (but could be done with a uint32).

The CBOR encoding is not impacted whatsoever for LSID. The SID values will just happen to fit in 16 or 31 bits.

A server implementation will create a data structure (e.g. JSON file like a SID file, but called an LSID file). The mapping is expected to be compressed so no LSID values are wasted.

The client will load the SID files and the LSID mapping. Code logic for the full SID will be mapped to the LSID. It is possible client applications could be hard-wired to use LSIDs for a specific mapping-id directly.

Most implementations (even YANG Push!) will have less than 64K schema items and can use LSID.16. This can help reduce server memory consumption and maximize on-the-wire efficiency.

 sx:structure lsid-file {
      leaf mapping-id {
          type string;
          description "Identify the server implementation that this mapping is for";
      }
      choice lsid-type {
        list lsid16 {
             key lsid;
             unique sid;
             leaf lsid { type uint16; }
             leaf sid {
                 type sid;
                 mandatory true;
             }
        }
        list lsid32 {
             key lsid;
             unique sid;
             leaf lsid {
                 type uint32 {
                     range "0 .. 2147483647";
                  }
             }
             leaf sid {
                 type sid;
                 mandatory true;
             }
        }
     }
 }

[mcr]

seems like an interesting implementation detail. I'm not sure that there are any on-the-wire implications... why is it our problem?

[abierman]

I am just vetting the idea to make sure there are no problems.

• do the SID and YANG-CBOR drafts have any text that requires SIDs to be used?
• Is an LSID considered to be a SID or something else (in the standard, not just on the wire)
• IETF is traditionally very picky about terminology and the scope of the terminology, so want to make sure a protocol adaptation such as LSID can be supported in the future

[abierman]

No issues discovered. Intent is to keep specification of SID assignments separate from CBOR encoding. This was confirmed in conf-call.