(Apologies for the very late arrival of this review and my having finger trouble with pressing the complete button in the datatracker.) I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-scim-device-model-15 Reviewer: Elwyn Davies Review Date: 2025-06-25 IETF LC End Date: 2025-05-12 IESG Telechat date: 2025-06-26 Summary: Not ready for publication as an RFC. The detail of the document is probably correct but the introduction and the description of the proposed architecture leaves much to be desired. I have to agree with Mohamed Boucadair's discuss comments regarding the appropriateness of this specification rather one of the other configuration mechanisms mentioned. Major issues: The whole of s1.2 that notionally describes the architecture of the system is very confused and confusing and needs to be thoroughly rewritten. Minor issues: The terms 'onboard' and 'onboarding' are now pretty well established in the IoT universe but they are jargon and I have been struggling to find good place for people from outside to understand the term and the the associated concepts. There do not appear (to me, at least) to be any published RFCs that this document might refer to as an illustrative reference. However, the Thing-to-Thing research group (t2trg) has a document in progress (draft-irtf-t2trg-security-setup-iot-devices) that would seem to fit the bill. I have asked the chairs of t2trg whether they concur and, if so, what the time scale for the publication of this work might be. I have had a reply from Ari and he agrees that this would be a useful reference - it is expected that this will advance to publication in a reasonably short timescale. It also refers to provisioning for devices which is also useful. Nits/editorial comments: General: A number of sections define attributes and such like by displaying the name and followed by a paragraph defining the item. It would be much clearer if either these were down as separate subsections or used paragraphs with hanging labels to clarify what is in the definition e,g (s2.1) OLD: id An id is a required and unique attribute of the device core schema (see section 3.1 of [RFC7643]). NEW: id An id is a required and unique attribute of the device core schema (see section 3.1 of [RFC7643]). s1 : As mentioned above the concepts of onboard/onboarding need to be introduced here. s1: I think it would also be useful to compare user and device provisioning to make it clear what device provisioning is intended to cover: User provisioning is the process of creating, maintaining, updating, and deleting a user’s account and access from multiple applications and systems all at once, be it on-premise, cloud-based, or a mix of both. Device provisioning refers to the process of preparing and configuring a device for use in a network or system. It involves setting up the device with the necessary software, settings, and security configurations to enable it to connect to the network and perform its intended functions. s1: The Introduction should list the proprietary systems (BLE etc) for which extension schemas are defined in Section 8 and give appropriate references for readers to find more information about these schemes. s1, 1st para: Introduce acronym IoT (It is not a well-known abbreviation for RFCs: s/Internet of Things/Internet of Things (IoT)/ s1, last para: A reference for the nature of BLE Just Works would be helpful (but not easy to find). Suggest The BLE Security Study Guide (https://www.bluetooth.com/bluetooth-resources/le-security-study-guide/). The t2trg draft mentioned above has outline information for the FIDO system and could be referenced. s1, last sentence: Possibly s/treated/managed/ s1.1: The rather 'chatty' tone of this section is not really appropriate to an RFC. Also I would present the four points as separate bullet items to make them stand out clearly. The anecdote about the San Francisco bilboard is inappropriate and adds nothing to the specificaion. My suggestion for the section would be: NEW 1.1. Why use SCIM for devices? There are a number of existing models that might provide the basis for a scheme for provisioning devices in an IoT environment, including two standardised by the IETF: NETCONF [RFC6241] or RESTCONF [RFC8040] with YANG [RFC7950]. Other models such as MQTT (Message Queuing Telemetry Transport) and Event Driven Architecture (EDA) systems are available. [I don't know exactly how relevant these might be but it might be worth mentioning other options here]. However there are a number of reasons why SCIM is better suited to the onboarding and management of potentially large numbers of devices: For example, NETCONF and RESTCONF focus on *configuration* rather than provisioning. SCIM is designed with inter-domain provisioning in mind. The use of HTTP as a substrate permits both user-based authentication for local provisioning applications, as well as OAUTH or certificate- bases authentication. The inter-domain nature of these operations does not expose local policy, which itself must be (and often is) configured with other APIs, many of which are not standardized. SCIM is also a familiar tool within the enterprise environment, used extensively to configure federated user accounts. Once a device onboarding and provisioning system, such as SCIM, is chosen for a deployment, operation of the system becomes dependent on there being a consistent and standardized data model being used by the devices being deployed. The SCIM data model is articulated and standardized in [RFC7643] . This taken together with the fact that end devices are not intended to be *directly* configured leave us with SCIM as the best standard option s1.2 and onward: I would prefer not to see the use of 'app' as an abbreviation in the document. s1.2/Figure 2: AAA needs to be expanded on first use (it isn't well-known) s1.2: The expansion of ALG should be given at the first instance of application layer gateway. Also the RFC editor abbreviations page suggest that hyphens should not be used in this term. s1.2, para after Figure 1: The last sentence is very confusing. I think s/to reach the endpoint/to reach the device/ Figures 1 and 2: Be consistent with capitalisation of words e.g., s/onboarding app/Onboarding App/ Figure 1: Surely the SCIM server must communicate with the device during onboarding? Maybe via the ALG?? Figure 1 and 2: What is the large box in the figures supposed to represent? Figure 1 and 2: Shouldn't there be some communication between the onboarding app(lication) and the Control App(lication)? Figure 1 and 2: Presumably the idea is that the connection into the large box from the Control App(lication) goes through the Control Endpoint. It would be helpful to label this if I am right. Figure 2: Why is there necessarily a 'switch' between the AAA and the device? If so what is its function? s1.3: RFC 7463 may not prescribe a schema description language but it is firmly committed to JSON and explicitly excludes XML (Section 2 of RFC 7463). It seems to me that it would be more useful just to commit this extension to be consistent with RFC 7463 and hence use JSON. s1.5: The terminology from RFC 7463 should be imported. This would then define terms such as Singular Attribute which is otherwise undefined here. s2 and onward: Please be consistent about use of 'device core schema' and the capitalisation of words in the name . Choose one of core device schema/device core schema and maybe even define an acronym. s2.1, para 1: s/the [RFC7463]/[RFC7463]/ s3.1, mudUrl: Expand MUD on first use. It would probably be helpful to reference RFC8520 at this point also. s3.1, last para and 7 other instances: s/Section Section/Section/ (remove Section before automatic expansion of XML cross reference) s3.1, last para and 7 other instances: s/Section Appendix/Appendix/ (remove Section before automatic expansion of XML cross reference) s6.1: This could also refer back to Section 2.1 in this document. s6.3.1, CODE section: s/"subjectName": "wwww.example.com"/"subjectName": "www.example.com"/ (I assume). s7.1, Title: Expand BLE please. s7.1.1: Expand MAC on first use. s9.1, para 1: s/we discuss each operation/each operation is discussed below/ [This is not a scientific paper!]