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

# 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.

# É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 ;-)

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

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.

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/

# 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	              <https://json-schema.org/draft/2020-12/json-schema-core>.
```

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.

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

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).