Re: [Rats] [Teep] EAT claims needed by TEEP

[Brendan Moran <[e-mail]>]

Strings are not the right choice for machine readable fields. There are extremely good reasons not to use them. Please do not use strings for model IDs.

When you have a string, it is inevitable that someone in marketing will realise that it’s human-readable. The next step is that it must be controlled to preserve brand image. When this happens, it is also inevitable that *wildly incompatible hardware* with *the same function* will be forced into the same “model number.”

By making model identification explicitly non-parseable by humans, we prohibit its use as a controllable, human facing identifier. This ensures that it has a better chance of being used correctly as a means to distinguish between mutually incompatible versions.

Human readable strings used as machine-readable distinguishing tokens are a bad idea. Don’t do it.

Brendan

On 10 Nov 2021, at 21:25, Laurence Lundblade <[e-mail]<mailto:[e-mail]>> wrote:

An advantage of a string over a UUID is that it can be very short if that’s all the OEM needs, “S”, “3, “X” and “Y” in the case of Tesla.

LL

On Nov 10, 2021, at 1:03 PM, Dave Thaler <[e-mail]<mailto:[e-mail]>> wrote:

If it's a string, I think it should be up to the vendor specified by the oemid,
rather than by a vendor-agnostic profile.
If it's a UUID then that's not needed.

Personally I would argue for treating it as opaque in either case
and a verifier should only compare it for equality, rather than permitting
semantic structure in it.   That's because I think some hardware implementation
may fillvin values that can be used for multiple profiles.

Dave

-----Original Message-----
From: RATS <[e-mail]<mailto:[e-mail]>> On Behalf Of Michael Richardson
Sent: Wednesday, November 10, 2021 12:23 PM
To: Laurence Lundblade <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; teep <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Rats] EAT claims needed by TEEP


Laurence Lundblade <[e-mail]<mailto:[e-mail]>> wrote:
Appreciate the comments.  Think it is important to keep this generic
since it is going in EAT. TEEP can have specific ways it uses HW class,
but don't think we should be referencing TEEP in EAT.

Then I suggest that:

    "There is no global scheme or format for this claim."
->
    "The format for this scheme will need to be specified within profiles that
     use it."

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [e-mail]<mailto:[e-mail]>  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sandelman.ca%2F&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C47461df1d4ae4c6cc7f208d9a487f27c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637721726675767230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2BOIH8fZw6zju18DcoR9hQ4HkrtDsMkhTXwQTitkKsSQ%3D&amp;reserved=0        |   ruby on rails    [


--
Michael Richardson <[e-mail]<mailto:[e-mail]>>, Sandelman Software Works  -= IPv6 IoT consulting =-

_______________________________________________
TEEP mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/teep

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.