(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
<https://wiki.ietf.org/en/group/gen/GenArtFAQ>
<https://wiki.ietf.org/en/group/gen/GenArtFAQ%3E>.
Document:draft-ietf-scim-device-model-15
<https://datatracker.ietf.org/doc/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 withMohamed
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:
1. For example, NETCONF and RESTCONF focus on *configuration* rather
than provisioning.
2. 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.
3. SCIM is also a familiar tool within the enterprise environment, used
extensively toconfigure federated user accounts.
4. 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!]
_______________________________________________
Gen-art mailing list -- [email protected]
To unsubscribe send an email to [email protected]
