Device Schema Extensions to the SCIM model
draft-ietf-scim-device-model-18

[Ballot comment]
Thank you for addressing my DISCUSS and COMMENT feedback.

Given the new text in -16, considering explicitly stating that the various examples are in JSON (e.g., Figure 3, 4, etc).

[Ballot comment]
Thanks for the productive discussion and resolving my comments.

It is now my understanding that you are not using the media type specified in "JSON Schema" but that you use RFC 7644 with skim+json encoding and that JSON Schema / openapi is just an informative helpful tooling informational reference.

I have updated my ballot to No Objection

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-scim-device-model-15
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Nancy Cam-Winget for the shepherd's detailed write-up including the WG consensus *but it lacks* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Section 1

Please add the references to BLE & FIDO.

### Section 1.1

The HTML rendering of the list is not really a bulleted list making parsing somehow difficult.

### Section 1.2

Please add an informative reference to `Wi-Fi Easy Connect` (DPP2)?

### Section 3.1

Please add a reference to MUD at first use.

### Section 7.3

Is MAB still valid with some OS doing MAC address randomization ? Cfr the MADINAS WG RFC. Should a note be added to this section ?

### Section 7.3.1

All previous deviceMacAddress were defined by a regex, any reason why it is not done here ?

### Section 7.5

Please add an informative reference to Zigbee.

I also wonder why Thread is not supported (cfr SNAC WG working in a Thread framework...).

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)

[Ballot discuss]
This is likely my misunderstanding of things.

This document seems to normatively reference "JSON Schema" which defines a media type of "application/schema+json", but this media type is not registered with IANA at https://www.iana.org/assignments/media-types/media-types.xhtml  ? Shouldn't it be registered at IANA before this document can use it? What if this website changes their media type ?

[Ballot comment]

        This is the base64 encoding a trust anchor certificate as
        described in [rfc4648] Section 4.

This confused me a little, I expected trust anchor certificate info
in RFC4648. Maybe:

        This is the base64 encoding ([rfc4648] Section 4) of a trust
        anchor certificate.


        Note that either clientToken and certificateInfo are used for
        the authentication of the application.

This does not parse, I suspect it should be "clientToken or certificateInfo"

        If certificateInfo is NOT present when an endpointApp is object
        created, then the server SHOULD return a clientToken. Otherwise,
        if the server accepts the certificateInfo object for
        authentication, it SHOULD NOT return a clientToken.

Why are these SHOULD/SHOULD NOT and not MUST/MUST NOT ?


        A boolean flag taken from the BLE core specification, 5.3.

Is 5.3 a BLE core specification version? If so please state that.

[Ballot comment]
I support Roman's DISCUSS regarding JSON Schema. While -15 moves it from a normative to an informative reference, it's not technically needed at all. RFC 7643 defines the format that this document implements; the fact that 7643 bears a striking resemblance to JSON Schema is not really this document's problem.

[Ballot comment]
Hi Muhammad, Hassan, and Eliot,

Thank you for addressing most of my DISCUSS points in -15 [1].

# Please add a reference of the OpenAPI Specification you are following.

# Why SCIM for devices?

CURRENT:
  Some might ask why SCIM is well suited for this purpose and not, for
  example, NETCONF [RFC6241] or RESTCONF [RFC8040] with YANG [RFC7950].
  After all, there are all sorts of existing models available.  The
  answer is four fold: - First, NETCONF and RESTCONF focus on
  *configuration* rather than provisioning. - Second, 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- based
  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 enviroment, used extensively to
  configure federated user accounts.  (Amusingly, one author noted a
  billboard in San Francisco highlighting a SCIM as part of a product
  capability.) - Finally, once one chooses a vehicle such as SCIM, one
  is beholden to its data model.  The SCM data model is articulated 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.

I’m not pushing for changing the design adopted in this spec, but I think some of the arguments listed above are questionable. For example:

* YANG can be used to model abstract data structures (RFC 8791) and you would have support for mapping to JSON (RFC7951) for free.
* The argument about HTTP is not specific to SCIM and can be claimed as well for RESTCONF

No need IMO to over-justify why SCIM is "superior". I would simplify here and simply say this spec is about applying SCIM to device provisioning.

BTW, the formatting is broken and there are several nits to fix (SCM, environment).

Not sure to see the value to include the note about "Amusingly, one author noted…"

# NMS Gateway

CURRENT:
  varied.  A deployment network management system gateway (NMS gateway)

I’m familiar with NMS, but this is the first time I hear about NSM gateway. What does that mean?

# Functional architecture


## BRSKI

The text surrounding the figure says:

      sometimes envisioned by Bootstrapping Remote Key Infrastructure
      (BRSKI) [RFC8995].

But what is the purpose of this mention? How this is useful in this context?

# Terminology

Please consider adding a note that this document uses the terms defined in rfc7643#section-1.2. Also, add a reference to rfc7643#section-2.2 for the Attribute Characteristics.

# Common Attributes (S 2.1)

Why those are repeated here? A pointer to rfc7643#section-3.1 would suffice. No?

## id

CURRENT:
  An id is a required and unique attribute of the device core schema
  (see section 3.1 of [RFC7643]).

What is the unicity scope of the id?

## externalID

CURRENT:
  An externalID is an optional attribute (see section 3.1 of
  [RFC7643]).

Not easy to digest what is meant here. Please grab more text from 7643.

## meta

CURRENT:
  Meta is a complex attribute and is required (see section 3.1 of
  [RFC7643]).

Not easy to digest what is meant. Please grab more text from 7643 or replace the section with a pointer to that RFC.

# Many nits

There are many nits in the document. I'm not listing all those here, but please do a full check of the text.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/scim/Ni9GdbZfTYqr_ednd1zl2b_gfqE/

[Ballot discuss]
** Section 1.3
  RFC 7643 does not prescribe a language to describe a schema.  We have
  chosen the JSON schema language [JSONSChema] for this purpose.

Can the use of [JSONSchema] be clarified.  This reference is informative, so how it is “chosen” by this draft is not clear.  Furthermore, [JSONSchema] doesn’t appear to be used in Section 8 (correct?).  Aren’t Sections 8.x JSON document which implements “schema” per RFC7643? 

** Section 8.  What is the formal format used in these sections?  Is the right normative reference JSON?

** Sections 8.x uses the “pattern” attribute in a few of the schemas.  Where is that attribute defined?  It is not RFC7643 (or in any of the normative references).

[Ballot comment]
** Section 1.1. Editorial
  (Amusingly, one author noted a
  billboard in San Francisco highlighting a SCIM as part of a product
  capability.)

Will this text age will in an archival document?  I recommend removing this text.

** Appendix B.  Please provide a reference to YAML as the formal language specifying the schemas in Appendices B1-B8.  Perhaps it could be:

[YAML] Ben-Kiki, O., Evans, C., dot Net, I., Müller, T., Antoniou, P., Aro, E., and T. Smith, "YAML Ain't Markup Language Version 1.2", 1 October 2021, .

[Ballot comment]
Thank you for this I-D.

I agree with Med's DISCUSS for the reference to JSON Schema. This reference needs to
be stable. I also agree with Med's advice suggesting the path followed by RFC7644

[Ballot comment]
# Orie Steele, ART AD, comments for draft-ietf-scim-device-model-14
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-scim-device-model-14.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

I support Med's discuss.

### Normative reference to expired ID indirectly

```
2499   [JSONSChema]
2500               Wright, A., Ed., Andrews, H. A., Ed., Hutton, B., Ed., and
2501               G. Dennis, "JSON Schema- A Media Type for Describing JSON
2502               Documents", December 2022,
2503               .
```

The URL referenced is hosting:

https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-01


### clientToken

Is this an identifier? are emoji's allowed?
Perhaps this is obvious to SCIM experts, but I wondered if this was a JWT or a "client id", similar to what we seein OAuth.

```
412   clientToken

414   This attribute type string contains a token that the client will use
415   to authenticate itself.  Each token may be a string up to 500
416   characters in length.  It is not mutable, read-only, generated if no
417   certificateInfo object is provisioned, case sensitive and returned by
418   default if it exists.  The SCIM server should expect that client
419   tokens will be shared by the SCIM client with other components within
420   the client's infrastructure.
```

Later in the table:

```
463     | clientToken    | F    |F  | T    | R      | N      | None  |
```

Implies that this is not returned?


### Why not must?

```
476   Note that either clientToken and certificateInfo are used for the
477   authentication of the application.  If certificateInfo is NOT present
478   when an endpointApp is object created, then the server SHOULD return
479   a clientToken.  Otherwise, if the server accepts the certificateInfo
```

### Why not JWK?

```
829   bootstrapKey

831   A string value representing an Elliptic-Curve Diffie-Hellman (ECDH)
832   public key.  The base64 encoded lengths for P-256, P-384, and P-521
833   are 80, 96, and 120 characters.  This attribute is required, case-
834   sensitive, mutable, and returned by default.
```

I assume these are expanded public keys, with or without the 04 prefix?
No need to support agility / PQ crypto here?
JWK also supports x5t, x5c, etc...
I assume the key is encoded like this to enable it to be easily pasted into some existing protocol slot.

[Ballot comment]
# Andy Newton, ART AD, comments for draft-ietf-scim-device-model-14
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-scim-device-model-14.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Discuss

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/,
a DISCUSS ballot is just a request to have a discussion on the following topics.

## Comments

### Normative Reference to JSON Schema

I concur with Med's DISCUSS regarding the reference to JSON Schema. This reference needs to
be stable. I also concur with Med's advice of using the path followed by RFC7644.

[Ballot discuss]
Hi Muhammad, Hassan, and Eliot,

Thank you for the effort put into this specification.

# Deployment model and Target SCIM Use Case

I must admit that despite several iterations, I’m having troubles to understand the deployment model assumed in this draft and how the various pieces fit together.

I also failed to conclude whether this extension is an elaborated use case of the reloaded SCIM use cases, specifically the device cases at https://datatracker.ietf.org/doc/html/draft-ietf-scim-use-cases-reloaded-00#name-device-identity-creation-fr or is this about something else.

Can we please clarify this in the document, including specifying where the various access-specific technologies APIs are invoked? Thank you.

# Normative dependency on an expired individual I-D

CURRENT:
  [JSONSChema]
              Wright, A., Ed., Andrews, H. A., Ed., Hutton, B., Ed., and
              G. Dennis, "JSON Schema- A Media Type for Describing JSON
              Documents", December 2022,
              .

This also corresponds to an expired individual I-D: https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-01. I'm afraid that progressing this spec will require this one to be advanced as well, No?

Maybe the intent at the first place is to present the JSON schema as non-normative? That seems more consistent with rfc7644. I encourage you explore that path.

[Ballot comment]
# Please add a reference of the OpenAPI Specification you are following.

# Why SCIM for devices?

CURRENT:
  Some might ask why SCIM is well suited for this purpose and not, for
  example, NETCONF [RFC6241] or RESTCONF [RFC8040] with YANG [RFC7950].
  After all, there are all sorts of existing models available.  The
  answer is four fold: - First, NETCONF and RESTCONF focus on
  *configuration* rather than provisioning. - Second, 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- based
  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 enviroment, used extensively to
  configure federated user accounts.  (Amusingly, one author noted a
  billboard in San Francisco highlighting a SCIM as part of a product
  capability.) - Finally, once one chooses a vehicle such as SCIM, one
  is beholden to its data model.  The SCM data model is articulated 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.

I’m not pushing for changing the design adopted in this spec, but I think some of the arguments listed above are questionable. For example:

* YANG can be used to model abstract data structures (RFC 8791) and you would have support for mapping to JSON (RFC7951) for free.
* The argument about HTTP is not specific to SCIM and can be claimed as well for RESTCONF

No need IMO to over-justify why SCIM is "superior". I would simplify here and simply say this spec is about applying SCIM to device provisioning.

BTW, the formatting is broken and there are several nits to fix (SCM, environment).

Not sure to see the value to include the note about "Amusingly, one author noted…"

# NMS Gateway

CURRENT:
  varied.  A deployment network management system gateway (NMS gateway)

I’m familiar with NMS, but this is the first time I hear about NSM gateway. What does that mean?

# Functional architecture

CURRENT:
                              +-----------------------------------+
                              |                                  |
      +-----------+  Request |  +---------+                      |
      | onboarding|------------->|  SCIM  |                      |
      |    app    |<-------------| Server  |                      |
      +-----------+  Ctrl Endpt  +---------+                      |
                              |                                  |
      +-----------+          |  +------------+        +-------+ |
      |  Control  |...........|..|    ALG    |.........|device | |
      |    App    |          |  +------------+        +-------+ |
      +-----------+          |                                  |
                              |                                  |
                              +-----------------------------------+

## Network mapping

Where is the network in this figure? Where the AAA mentioned in the introduced hosted in this figure?

## ALG

This figure seems to imply that an ALG is always needed to interact with a device. I understood this is to handle non-IP devices. Can we cite examples of such devices? Also, can we make it clear this is not required to be always involved.

## BRSKI

The text surrounding the figure says:

      sometimes envisioned by Bootstrapping Remote Key Infrastructure
      (BRSKI) [RFC8995].

But what is the purpose of this mention? How this is useful in this context?

# Terminology

Please consider adding a note that this document uses the terms defined in rfc7643#section-1.2. Also, add a reference to rfc7643#section-2.2 for the Attribute Characteristics.

# Common Attributes (S 2.1)

Why those are repeated here? A pointer to rfc7643#section-3.1 would suffice. No?

## id

CURRENT:
  An id is a required and unique attribute of the device core schema
  (see section 3.1 of [RFC7643]).

What is the unicity scope of the id?

## externalID

CURRENT:
  An externalID is an optional attribute (see section 3.1 of
  [RFC7643]).

Not easy to digest what is meant here. Please grab more text from 7643.

## meta

CURRENT:
  Meta is a complex attribute and is required (see section 3.1 of
  [RFC7643]).

Not easy to digest what is meant. Please grab more text from 7643 or replace the section with a pointer to that RFC.

# Many nits

There are many nits in the document. I'm not listing all those here, but please do a full check of the text.

Cheers,
Med

[Ballot discuss]
Hi Muhammad, Hassan, and Eliot,

Thank you for the effort put into this specification.

# Deployment model and Target SCIM Use Case

I must admit that despite several iterations, I’m having troubles to understand the deployment model assumed in this draft and how the various pieces fit together.

I also failed to conclude whether this extension is an elaborated use case of the reloaded SCIM use cases defined, specifically the device case at https://datatracker.ietf.org/doc/html/draft-ietf-scim-use-cases-reloaded-00#name-device-identity-creation-fr or something else.

Can we please clarify this in the document, including specifying where the various access-specific technologies API are invoked? Thank you.

# Normative dependency on an expired individual I-D

CURRENT:
  [JSONSChema]
              Wright, A., Ed., Andrews, H. A., Ed., Hutton, B., Ed., and
              G. Dennis, "JSON Schema- A Media Type for Describing JSON
              Documents", December 2022,
              .

This also corresponds to an expired individual I-D: https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-01. I'm afraid that progressing this spec will require this one to be advanced as well, No?

Maybe the intent at the first place is to present the JSON scheme as non-normative? That seems more consistent with rfc7644. I encourage you explore that path.

[Ballot comment]
# Please add a reference of the OpenAPI Specification you are following.

# Why SCIM for devices?

CURRENT:
  Some might ask why SCIM is well suited for this purpose and not, for
  example, NETCONF [RFC6241] or RESTCONF [RFC8040] with YANG [RFC7950].
  After all, there are all sorts of existing models available.  The
  answer is four fold: - First, NETCONF and RESTCONF focus on
  *configuration* rather than provisioning. - Second, 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- based
  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 enviroment, used extensively to
  configure federated user accounts.  (Amusingly, one author noted a
  billboard in San Francisco highlighting a SCIM as part of a product
  capability.) - Finally, once one chooses a vehicle such as SCIM, one
  is beholden to its data model.  The SCM data model is articulated 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.

I’m not pushing for changing the design adopted in this spec, but I think some of the arguments listed above are questionable:

• YANG can be used to model abstract data structures (RFC 8791) and you would have support for mapping to JSON (RFC7951) for free.
• The argument about HTTP is not specific to SCIM and can be claimed as well for RESTCONF

No need IMO to over-justify why SCIM is “superior”. I would simplify here and simply say this spec is avoid applying SCIM to device provisioning.

BTW, the formatting is broken and there are several nits to fix (SCM, environment).

Not sure to see the value to include the note about “Amusingly, one author noted…”

# NMS Gateway

CURRENT:
  varied.  A deployment network management system gateway (NMS gateway)

I’m familiar with NMS, but this is the first time I hear about NSM gateway. What does that mean?

# Functional architecture

CURRENT:
                              +-----------------------------------+
                              |                                  |
      +-----------+  Request |  +---------+                      |
      | onboarding|------------->|  SCIM  |                      |
      |    app    |<-------------| Server  |                      |
      +-----------+  Ctrl Endpt  +---------+                      |
                              |                                  |
      +-----------+          |  +------------+        +-------+ |
      |  Control  |...........|..|    ALG    |.........|device | |
      |    App    |          |  +------------+        +-------+ |
      +-----------+          |                                  |
                              |                                  |
                              +-----------------------------------+

## Network mapping

Where is the network in this figure? Where the AAA mentioned in the introduced hosted in this figure?

## ALG

This figure seems to apply that an ALG is always needed to interact with a device. I understood this is to handle non-IP devices. Can we cite examples of such devices? Also, can we make it clear this is not required.

## BRSKI

The text surrounding the figure says:

      sometimes envisioned by Bootstrapping Remote Key Infrastructure
      (BRSKI) [RFC8995].

But what is the purpose of this mention? How this is useful in this context?

# Terminology

Please consider adding a note that this document uses the terms defined in rfc7643#section-1.2. Also, add a reference to rfc7643#section-2.2 for the Attribute Characteristics.

# Common Attributes (S 2.1)

Why those are repeated here? A pointer to rfc7643#section-3.1 would suffice. No?

## id

CURRENT:
  An id is a required and unique attribute of the device core schema
  (see section 3.1 of [RFC7643]).

What is the unicity scope of the id?

## externalID

CURRENT:
  An externalID is an optional attribute (see section 3.1 of
  [RFC7643]).

Not easy to digest what is meant here. Please grab more text from 7643

## meta

CURRENT:
  Meta is a complex attribute and is required (see section 3.1 of
  [RFC7643]).

Not easy to digest what is meant. Please grab more text from 7643 or replace the section with a pointer to that RFC.

# Many nits

There are many nits in the document. I'm not listing all those here, but please do a full check of the text.

Cheers,
Med

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-scim-device-model-12. If any part of this review is inaccurate, please let us know.

IANA has a question about one of the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the SCIM Schema URIs for Data Resources registry in the System for Cross-domain Identity Management (SCIM) Schema URIs registry group located at:

https://www.iana.org/assignments/scim/

two new URNs are to be registered as follows:

URN: urn:ietf:params:scim:schemas:core:2.0:Device
Name: Core Device Schema
Reference: [ RFC-to-be; Section 3 ]

URN: urn:ietf:params:scim:schemas:core:2.0:EndpointApp
Name: Endpoint Application
Reference: [ RFC-to-be; Section 6 ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request.

Second, a new registry is to be created called the Device Schema Extensions registry.

IANA QUESTION -> Where should this new registry be located? Is it a new registry on the IANA Matrix or is it a subregistry of an existing registry? If it is a subregistry of an existing registry, in which registry will it be contained?

The registration policy for the new registry will be Specification Required as defined in [RFC8126].

There are initial registrations in the new registry as follows:

URN: urn:ietf:params:scim:schemas:extension: ble:2.0:Device
Description: BLE Extension
Reference: [ RFC-to-be; Section 7.1 ]

URN: urn:ietf:params:scim:schemas:extension:ethernet-mab:2.0:Device
Description: Ethernet MAB
Reference: [ RFC-to-be; Section 7.3 ]

URN: urn:ietf:params:scim:schemas:extension:fido-device-onboard:2.0:Device
Description: FIDO Device Onboard
Reference: [ RFC-to-be; Section 7.4]

URN: urn:ietf:params:scim:schemas:extension:dpp:2.0:Device
Description: Wi-fi Easy Connect
Reference: [ RFC-to-be; Section 7.2]

URN: urn:ietf:params:scim:schemas:extension:endpointAppsExt:2.0:Device
Description: Application Endpoint Extension
Reference: [ RFC-to-be; Section 7.1.3]

URN: urn:ietf:params:scim:schemas:extension:pairingJustWorks:2.0:Device
Description: Just Works Auth BLE
Reference: [ RFC-to-be; Section 7.1.3]

URN: urn:ietf:params:scim:schemas:extension:pairingOOB:2.0:Device
Description: Out of Band Pairing for BLE
Reference: [ RFC-to-be; Section 7.1.3]

URN: urn:ietf:params:scim:schemas:extension:pairingPassKey:2.0:Device
Description: Passkey Pairing for BLE
Reference: [ RFC-to-be; Section 7.1.3]

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-05-12):

From: The IESG
To: IETF-Announce
CC: debcooley1@gmail.com, draft-ietf-scim-device-model@ietf.org, ncamwing@cisco.com, scim-chairs@ietf.org, scim@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Device Schema Extensions to the SCIM model) to Proposed Standard


The IESG has received a request from the System for Cross-domain Identity
Management WG (scim) to consider the following document: - 'Device Schema
Extensions to the SCIM model'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-05-12. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The initial core schema for SCIM (System for Cross Identity
  Management) was designed for provisioning users.  This memo specifies
  schema extensions that enables provisioning of devices, using various
  underlying bootstrapping systems, such as Wi-fi Easy Connect, FIDO
  device onboarding vouchers, BLE passcodes, and MAC authenticated
  bypass.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-scim-device-model/



No IPR declarations have been submitted directly on this I-D.

Shepherd writeup for draft-ietf-scim-device-model-11

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
There is general consensus in the SCIM participants with broad agreement to move this document forward.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
No controversy. Initial discussions were aligned to the use cases that drove the re-chartering of the working group; since this draft's adoption, there was been discussion, clarifications and early reviews from both the IoT and Security directorates whose comments have been addressed.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
No

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
Yes, there are several implementations, beginning with the open source
code at https://github.com/iot-onboarding/tiedie (OSS).  There are some
commercial implementations based on recent drafts but are awaiting for the publication of this draft.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
No

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
Beyond the working group reviews, this draft received early reviews by both the SECdir and IOTdir to ensure expert reviews were done to ensure draft direction and readiness.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
No, YANG is not used or specified in this draft.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
None was needed.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?
I have reviewed the document and believe it is ready for Area Directory review.
The authors will have to work with IANA and assign reviewer/approvers (subject matter experts) to assist assignment of future requests to the new resource type registry.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
This draft received early reviews by both the SECdir and IOTdir to ensure security and privacy considerations were on the proper track; similarly as this draft defines the means for identifying, especially, constrained devices a review by the IOTdir was requested.  As it was an early draft, the IOTdir provided good reviews and noted it was technically on the right track.  There was discussion and follow-up between the SECdir and the draft authors to resolve the commenters concerns on use case and security considerations.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?
Request is for “Proposed Standard”, the datatracker and draft reflect the
intent.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
Yes, we did a query to the SCIM mail list as well as a unicast request to the
draft authors and no IPR disclosures were submitted or known to the
participants.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
The SCIM Device Model draft appears to follow the I-D style guidelines. The draft appears to make proper use of
RFC2119 for normative statements. Idnits is reporting some erroneous warnings to acronyms as being downref or missing references.  There is an encoding issue of one character which the authors hope the rfc editor can help correct at that stage.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
None were identified.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
All normative references are freely available.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
None were identified.


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
None were identified.


19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
No

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
This draft extends the SCIM core schema to allow for a new resource type, described in Section 8.1 of the draft.  Rather than creating an extension, a new IANA registry is defined to allow for devices to be defined by their own schema.  Each schema MUST be registered with the requirements and descriptions defined in section 10.2.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.
The newly defined Device Resource type as its own IANA registry will require review in future allocations (these are described in section 10). Eliot Lear
would be the appropriate designated expert.