Subject: [Rats] Pre-allocation of three additional code points for EAT

From: "Smith, Ned" <[email-masked]>
Date: Sun, 13 Feb 2022 03:17:21 +0000

The EAT draft would like to request pre-allocation of these code points:
sueids-label = 257
hardware-model-label = 259
hardware-version-label = 260

Does the list support making these pre-allocations? 

If the pre-allocation is made but the RATS WG wants to change either formatting or semantics, then that can't happen. If anyone anticipates making tweaks please speak up now.

The AD will reference this thread as evidence of WG consensus for the record.

Thanks,
RATS Chairs

---

From: Michael Richardson <[email-masked]>
Date: Sun, 13 Feb 2022 15:27:33 -0500

I went to read again the three claims.

    > The EAT draft would like to request pre-allocation of these code points:

https://www.ietf.org/archive/id/draft-ietf-rats-eat-11.html#name-semi-permanent-ueids-sueids
okay, the "SEUID is of the same format as a UEID", with a label in a map.

    > hardware-version-label = 260

I couldn't find these in eat-11.
https://www.ietf.org/archive/id/draft-ietf-rats-eat-11.html#name-hardware-version-claims-har
is the closest I could find.
Am I missing something?

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 14 Feb 2022 18:53:54 +0000

Section 3.7 in github https://ietf-rats-wg.github.io/eat/draft-ietf-rats-eat.html has the following definitions for hardware-model-type [1] and hw-version-type [2]. I'm assuming there is a typo for hw-version-label (vs. hardware-version-label).

[1]
This claim differentiates hardware models, products and variants manufactured by a particular OEM, the one identified by OEM ID in Section 3.6.

This claim must be unique so as to differentiate the models and products for the OEM ID. This claim does not have to be globally unique, but it can be. A receiver of this claim MUST not assume it is globally unique. To globally identify a particular product, the receiver should concatenate the OEM ID and this claim.

The granularity of the model identification is for each OEM to decide. It may be very granular, perhaps including some version information. It may be very general, perhaps only indicating top-level products.

The purpose of this claim is to identify models within protocols, not for human-readable descriptions. The format and encoding of this claim should not be human-readable to discourage use other than in protocols. If this claim is to be derived from an already-in-use human-readable identifier, it can be run through a hash function.

There is no minimum length so that an OEM with a very small number of models can use a one-byte encoding. The maximum length is 32 bytes. All receivers of this claim MUST be able to receive this maximum size.

The receiver of this claim MUST treat it as a completely opaque string of bytes, even if there is some apparent naming or structure. The OEM is free to alter the internal structure of these bytes as long as the claim continues to uniquely identify its models.

hardware-model-type = bytes .size (1..32)

$$claims-set-claims //= (
    hardware-model-label => hardware-model-type
)

[2]
The hardware version is a text string the format of which is set by each manufacturer. The structure and sorting order of this text string can be specified using the version-scheme item from CoSWID [CoSWID]. It is useful to know how to sort versions so the newer can be distinguished from the older.

The hardware version can also be given by a 13-digit [EAN-13]. A new CoSWID version scheme is registered with IANA by this document in Section 9.3.3. An EAN-13 is also known as an International Article Number or most commonly as a bar code.

$$claims-set-claims //=  (
    hw-version-label => hw-version-type
)

hw-version-type = [
    version:  tstr,
    scheme:  $version-scheme
]

On 2/13/22, 12:27 PM, "Michael Richardson" <[email-masked]> wrote:

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 14 Feb 2022 12:11:13 -0800

Thanks for posting the text, Ned.

It’s true that hardware-model hasn’t been published in a draft yet. It is only in the tip in GitHub. Apologies for confusion because of that.

Additionally, hardware-version has been modified substantially in the tip in GitHub. It used to be three claims, one for chip, one for board and one for device. Again, apologies for confusion around that.

I don’t mind dropping early allocation for these (but I’d like to do it by keeping the numbers and marking them TBD so they stay sequential). 

I do think they are required for the final document because OEM ID+Model+Version is an important way to represent device identity.

LL

> On Feb 14, 2022, at 10:53 AM, Smith, Ned <[email-masked]> wrote:
> 
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 14 Feb 2022 21:39:50 +0000

Laurence,
Are the EAT authors officially asking to withdraw hardware-model-label and hw-version-label (or hardware-version-label) code points from early allocation request?
Thanks,
-Ned

On 2/14/22, 12:11 PM, "Laurence Lundblade" <[email-masked]> wrote:

    LL

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 15 Feb 2022 10:33:27 -0800

I’m not officially asking to withdraw them, but if they are the cause of delay to the early allocation, I am personally OK with them being withdrawn.

LL

> On Feb 14, 2022, at 1:39 PM, Smith, Ned <[email-masked]> wrote:
> 
> Laurence,

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Feb 2022 18:45:31 -0500

> It’s true that hardware-model hasn’t been published in a draft yet. It
    > is only in the tip in GitHub. Apologies for confusion because of that.

integers are cheap and unlimited, next time, please post a new version before
we have this kind of discussion :-)

    > Additionally, hardware-version has been modified substantially in the
    > tip in GitHub. It used to be three claims, one for chip, one for board
    > and one for device. Again, apologies for confusion around that.

    > I don’t mind dropping early allocation for these (but I’d like to do it
    > by keeping the numbers and marking them TBD so they stay sequential).

I'm not sure that is possible.
If you are reserving the numbers, then you are reserving the numbers.
Do one or the other :-)

    > I do think they are required for the final document because OEM
    > ID+Model+Version is an important way to represent device identity.

okay.