Elwyn, Thank you for your thorough review. The authors will publish an updated version that includes AD comments, and changes based on your review in due course.
Please see below: > On 25 Jun 2025, at 13:22, Elwyn Davies <[email protected]> wrote: > > > 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. > Hopefully based on the below, you will feel differently. > 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. As you write, this terminology is very well understood within the IoT community, although it is often well understood in different ways ;-). I am reticent to try to constrain the definition because as a foundational technology, people may define uses we haven’t considered (c.f., RFC 5218). That is actually already happening. FDO shows just how broad the use can be, but I could easily envision, for instance, a “virtual device” being provisioned as part of a workload management system. We don’t talk about that in the draft, but one could go there. > > 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. > Were we writing a text book, I might agree. But I don’t think the above text belongs in a specification. We already state the following: > A primary purpose of this specification is to provision the network > for onboarding and communications access to and from devices within a > local deployment based on the underlying capabilities of those > devices. I think that’s probably enough. > 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. > We do that, but I want to be careful about hyping any particular proprietary mechanism. > > s1, 1st para: Introduce acronym IoT (It is not a well-known abbreviation for > RFCs: s/Internet of Things/Internet of Things (IoT)/ > We don’t actually use the term anywhere else in the document. Can you believe that? > 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. > I have it in the specification. Will update the reference. > s1, last sentence: Possibly s/treated/managed/ > Ok. > 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. > Removed. > 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] . We’ve taken much of your wording for the chapeau and largely left the bullets alone. > 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. > Ok > s1.2/Figure 2: AAA needs to be expanded on first use (it isn't well-known) > Done directly below. > 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. > This is done directly below the diagram. > s1.2, para after Figure 1: The last sentence is very confusing. I think s/to > reach the endpoint/to reach the device/ > Righto. > Figures 1 and 2: Be consistent with capitalisation of words e.g., > s/onboarding app/Onboarding App/ > App is now expanded to application, and we will do it all in lower case. > Figure 1: Surely the SCIM server must communicate with the device during > onboarding? Maybe via the ALG?? > No. This is a key point that the draft makes: SCIM is configuring the network, not the device, although extensions such as FIDO and DPP might later configure a device. > > Figure 1 and 2: What is the large box in the figures supposed to represent? > An local network. Will label. > Figure 1 and 2: Shouldn't there be some communication between the onboarding > app(lication) and the Control App(lication)? > Yes. A provisioning operation. Line added. > 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. > We’re giving a narrative description directly below. > Figure 2: Why is there necessarily a 'switch' between the AAA and the device? > If so what is its function? > It connects the device in a network. I think this is well enough understood not to have to label it. Also, we’re giving a narrative description directly below. > 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. > We give complete examples, as RFC 7643. > s1.5: The terminology from RFC 7463 should be imported. This would then > define terms such as Singular Attribute which is otherwise undefined here. > I added a note in the Terminology section. > 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. > We’ve attempted to clean that up. > s2.1, para 1: s/the [RFC7463]/[RFC7463]/ > Corrected. > s3.1, mudUrl: Expand MUD on first use. It would probably be helpful to > reference RFC8520 at this point also. > Added. > s3.1, last para and 7 other instances: s/Section Section/Section/ (remove > Section before automatic expansion of XML cross reference) > Corrected. > s3.1, last para and 7 other instances: s/Section Appendix/Appendix/ (remove > Section before automatic expansion of XML cross reference) > Corrected. > s6.1: This could also refer back to Section 2.1 in this document. > Ok. > s6.3.1, CODE section: s/"subjectName": "wwww.example.com"/"subjectName": > "www.example.com <http://www.example.com/>"/ (I assume). > Right. > s7.1, Title: Expand BLE please. > Done. > s7.1.1: Expand MAC on first use. > This one we should have the RFC editor to make a call on. I think it’s pretty well understood, but reasonable people might disagree. > s9.1, para 1: s/we discuss each operation/each operation is discussed below/ > [This is not a scientific paper!] > “specify”. Again, thanks very much! Eliot
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
