Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\))
From: Kaelin Foody <kfoody@staff.rfc-editor.org>
In-Reply-To: <471F8C43-1DDE-4090-A1EF-4E786DBA55E7@cisco.com>
Date: Fri, 13 Mar 2026 12:24:24 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <37B73CF9-2EF0-4112-8631-9D332CFD84DD@staff.rfc-editor.org>
References: <20260311184114.8A805C000CC3@rfcpa.rfc-editor.org>
 <471F8C43-1DDE-4090-A1EF-4E786DBA55E7@cisco.com>
To: Eliot Lear <lear=40cisco.com@dmarc.ietf.org>
Message-ID-Hash: BFJ4RE5UWTXV7YQRLRQKI72PHDTU5PZ2
CC: rfc-editor@rfc-editor.org, Muhammed Shahzad <mshahza@ncsu.edu>,
 hassaniqbal931@gmail.com, scim-ads@ietf.org, scim-chairs@ietf.org,
 ncamwing@cisco.com, debcooley1@gmail.com, auth48archive@rfc-editor.org
Precedence: list
Subject: =?utf-8?q?=5Bauth48=5D_Re=3A_=5BSUSPICIOUS=5D_AUTH48=3A_RFC-to-be_9944_=3Cdr?=
 =?utf-8?q?aft-ietf-scim-device-model-18=3E_for_your_review?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/auth48archive/tHh4s5vbWCSYcMXJYAHae9Fe4uk>

Hi Eliot, all,

Thanks for your reply.=20

We will wait to receive those updates from you before proceeding and can =
address the other items afterward.

All the best,

Kaelin Foody
RFC Production Center

> On Mar 13, 2026, at 7:50=E2=80=AFAM, Eliot Lear =
<lear=3D40cisco.com@dmarc.ietf.org> wrote:
>=20
> Hello RFC Editor and thanks for your efforts.
>=20
> There are, I think several issues with the draft RFC that we would =
like to address before going too far.  The first is that the last =
graphic in the text version (Appendix C) seems to have been smushed.  In =
addition, and for this one, I apologize, I think we need to reflow the =
JSON in accordance with RFC 8792.  Can we address that first?
>=20
> Eliot
>=20
>> On 11 Mar 2026, at 19:41, rfc-editor@rfc-editor.org wrote:
>>=20
>> Authors,
>>=20
>> While reviewing this document during AUTH48, please resolve (as =
necessary) the following questions, which are also in the source file.
>>=20
>> 1) <!-- [rfced] Please note that the title of the document has been =
updated as
>> follows:
>>=20
>> Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC
>> Style Guide"). Please review.
>>=20
>> Original:
>>=20
>>   Device Schema Extensions to the SCIM model
>>=20
>> Current:
>>=20
>>   Device Schema Extensions to the System for Cross-Domain Identity
>>                       Management (SCIM) Model
>>=20
>> -->
>>=20
>>=20
>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear =
in
>> the title) for use on =
https://secure-web.cisco.com/1PPb7iv5yqbTuUJm-V3VX5WNLACWX6bTxg1xViQShhKe4=
erOXftZkZO31gWpaQ35KyFJ5dlGheldlVukVzD4tVLNPGMpbs7JwcabledoVGPxduQ3gapB0Sn=
pfd7AClpcTlkgxhvhd_VgGZ5DYTDtyyheJoSXU8e9MNuTzgMMKVORG0Egx1seg0tmWEJ0X95er=
0xCHeVN6dPn3WUceHKZfR1aNRJPl57lIXc3zA-p7s9K9kgQcdgqW_j5o7lRCxLO84rn2KZGlSW=
ABBdGPSm7NFwZXnbVVI6yYRtEWErQhubhjkRfK2k9qbTqF-5EghGec/https%3A%2F%2Fwww.r=
fc-editor.org%2Fsearch -->
>>=20
>>=20
>> 3) <!-- [rfced] In the text below, we have updated "JSON Schema" to =
"JSON Schemas" (plural)=20
>> and "OpenAPI" to "OpenAPI versions" (for consistency with the first =
sentence).
>> Please review to confirm these changes are accurate.
>>=20
>> Original:
>>=20
>>  In addition, we provide non-normative JSON Schema [JSONSchema] and =
OpenAPI
>>  [OpenAPI] versions in the appendices for ease of implementation, =
neither of
>>  which existed when SCIM was originally developed.  The only =
difference the
>>  authors note between the normative schema representations is that =
JSON
>>  Schema and OpenAPI do not have a means to express...
>>=20
>> Current:
>>=20
>>  In addition, we provide non-normative JSON Schemas [JSONSchema] and =
OpenAPI
>>  [OpenAPI] versions in the appendices for ease of implementation, =
neither of
>>  which existed when SCIM was originally developed.  The only =
difference the
>>  authors note between the normative schema representations is that =
the JSON
>>  Schemas and OpenAPI versions do not have a means to express...
>>=20
>> -->
>>=20
>>=20
>> 4) <!-- [rfced] Could the citations below be updated as follows for =
clarity?
>> We ask because it appears that attribute characteristics are defined=20=

>> in Section 2.2 of RFC 7643, and that attribute datatypes are defined
>> in Section 2.3 of RFC 7643.
>>=20
>> Original:
>>=20
>>  Attributes defined in the device core schema and extensions comprise
>>  characteristics and SCIM datatypes defined in Sections 2.2 and 2.3 =
of
>>  [RFC7643].
>>=20
>> Perhaps:
>>=20
>>  Attributes defined in the device core schema (see Section 2.2 of
>>  [RFC7643]) and extensions comprise characteristics and the SCIM =
datatypes
>>  (defined in Section 2.3 of [RFC7643]).
>>=20
>> -->
>>=20
>>=20
>> 5) <!-- [rfced] For clarity, may we update the text below as follows? =
Note that
>> this update is similar to text that appears in Appendix A.2.
>>=20
>> Original:
>>=20
>>     For example, when used in conjunction with NIPC =
[I-D.brinckman-nipc],
>>     commands such as connect, disconnect, subscribe that control =
application
>>     sends to the controller for the devices any command will be =
rejected by
>>     the controller.
>>=20
>> Perhaps:
>>=20
>>     For example, when used in conjunction with Non-IP Device Control =
(NIPC) [NIPC],
>>     commands (such as connect, disconnect, and subscribe) that =
control application
>>     sends to the controller for devices will be rejected by the =
controller.
>>=20
>> -->
>>=20
>>=20
>> 6) <!-- [rfced] To make this definition more concise, may we combine =
the second
>> and fifth sentences as follows?
>>=20
>> Original:
>>=20
>>  mudUrl:  A string that represents the URL to the Manufacturer Usage
>>     Description (MUD) file associated with this device.  This
>>     attribute is optional and mutable.
>>     The mudUrl value is case sensitive and not unique. =20
>>     When present, this attribute may be used as described in =
[RFC8520].
>>     This attribute is case sensitive and returned by default.
>>=20
>> Perhaps:
>>=20
>>  mudUrl:  A string that represents the URL to the Manufacturer Usage
>>     Description (MUD) file associated with this device.  This
>>     attribute is optional, case sensitive, mutable, and returned by =
default.
>>     When present, this attribute may be used as described in =
[RFC8520].     =20
>>     The mudUrl value is case sensitive and not unique.
>>=20
>> -->
>>=20
>>=20
>> 7) <!-- [rfced] Please review the following questions regarding the =
notation used
>> in Tables 1 through 8:
>>=20
>> a) We note different notation used for "ReadOnly" in
>> these tables ("R" vs. "RO"). Please review and let us know
>> which form you prefer so we may update for consistency:
>>=20
>>  R:  ReadOnly
>>  RO:  ReadOnly
>>=20
>> b) We note these notations also appear with and without a space. =
Please review
>> and let us know how to update for consistency:
>>=20
>>  WO:  Write Only
>>  WO:  WriteOnly
>>=20
>> c) We note that "Manuf" is not included in Table 2. May we remove it =
from the
>> legend listed directly after the table?
>>=20
>>  Manuf:  Manufacturer
>>=20
>> -->
>>=20
>>=20
>> 8) <!-- [rfced] May we adjust these definitions below in order to =
clarify what
>> list items "not" refers to?
>>=20
>> Original:
>>=20
>>  It is not mutable, read-only, generated if no certificateInfo
>>  object is provisioned, case sensitive and returned by default if it =
exists.
>>  ...
>>  This attribute is not required, mutable, singular and NOT case
>>  sensitive.
>>  ...
>>  It is not required, multivalued, mutable, and returned by default.
>>=20
>> Perhaps:
>>=20
>>  It is not mutable. It is read only, case sensitive, and generated if =
no certificateInfo
>>  object is provisioned. It is returned by default if it exists.
>>  ...
>>  This attribute is not required and not case sensitive. It is mutable =
and singular.
>>  ...
>>  It is not required. It is multivalued, mutable, and returned by =
default.
>>=20
>> -->
>>=20
>>=20
>> 9) <!-- [rfced] How may we clarify "a trust anchor certificate" in =
the first sentence
>> below? In addition, may we adjust the second sentence as follows, in =
order to=20
>> clarify what list items "not" refers to?
>>=20
>> Original:
>>=20
>>  rootCA:  A base64-encoded string as described in [RFC4648] Section 4
>>     a trust anchor certificate.  This trust anchor is applicable for
>>     certificates used for client application access.
>>     The object is not required, singular, case sensitive, and =
read/write. =20
>>=20
>> Perhaps:
>>=20
>>  rootCA:  A base64-encoded string as described in Section 4 of
>>     [RFC4648]. It is a trust anchor certificate applicable for=20
>>     certificates used for client application access.
>>     The object is not required. It is singular, case sensitive, and =
read/write.
>>=20
>> -->
>>=20
>>=20
>> 10) <!-- [rfced] May we adjust the text below as follows to make =
these list items
>> more parallel and readable?
>>=20
>> Original:
>>=20
>>  SCIM provides various extension schemas, their attributes, JSON
>>  representation, and example object. =20
>>=20
>> Perhaps:
>>=20
>>  SCIM provides various extension schemas and their attributes, along =
with JSON
>>  representations and example objects.
>>=20
>> -->
>>=20
>>=20
>> 11) <!--[rfced] Because these following URNs appear in an ordered =
list, the
>> indentation causes the lines to exceed the 72-character limit. In =
order to
>> fit the character limit, we suggest converting the ordered list into =
a
>> definitions list as follows. Please review.
>>=20
>> Current:
>>=20
>>  ii.   The pairingJustWorks extension is identified using the
>>        following schema URI:
>>=20
>>        =
urn:ietf:params:scim:schemas:extension:pairingJustWorks:2.0:Device
>>=20
>>        The Just Works pairing method does not require a key to pair
>>        devices.  For completeness, the key attribute is included and
>>        is set to 'null'.  The key attribute is required, immutable,
>>        and returned by default.
>>=20
>>  iii.  The pairingPassKey extension is identified using the following
>>        schema URI:
>>=20
>>        =
urn:ietf:params:scim:schemas:extension:pairingPassKey:2.0:Device
>>=20
>>        The passkey pairing method requires a 6-digit key to pair
>>        devices.  This extension has one singular integer attribute,
>>        "key", which is required, mutable, and returned by default.
>>        The key pattern is as follows:
>>=20
>>     ^[0-9]{6}$
>>=20
>> Perhaps:
>>=20
>>  pairingJustWorks extension:  Identified using the following schema
>>     URI:
>>=20
>>     =
urn:ietf:params:scim:schemas:extension:pairingJustWorks:2.0:Device
>>=20
>>     The Just Works pairing method does not require a key to pair
>>     devices.  For completeness, the key attribute is included and is
>>     set to 'null'.  The key attribute is required, immutable, and
>>     returned by default.
>>=20
>>  pairingPassKey extension: Identified using the following
>>     schema URI:
>>=20
>>     urn:ietf:params:scim:schemas:extension:pairingPassKey:2.0:Device
>>=20
>>     The passkey pairing method requires a 6-digit key to pair
>>     devices.  This extension has one singular integer attribute,
>>     "key", which is required, mutable, and returned by default.
>>     The key pattern is as follows:
>>=20
>>  ^[0-9]{6}$
>> -->
>>=20
>>=20
>> 12) <!-- [rfced] How may we make the two instances below complete =
sentences in
>> order to provide more context for the reader?
>>=20
>> Original:
>>=20
>> 7.2.  Wi-Fi Easy Connect Extension
>>=20
>>  A schema that extends the device schema to enable Wi-Fi Easy Connect
>>  (otherwise known as Device Provisioning Protocol or DPP). =20
>>=20
>> 7.5.  Zigbee Extension
>>=20
>>  A schema that extends the device schema to enable the provisioning =
of
>>  Zigbee devices [Zigbee].
>>=20
>> Perhaps:
>>=20
>> 7.2.  Wi-Fi Easy Connect Extension
>>=20
>>  This section describes a schema that extends the device schema to =
enable Wi-Fi Easy Connect
>>  (otherwise known as Device Provisioning Protocol (DPP)).
>>=20
>> 7.5.  Zigbee Extension
>>=20
>>  This section describes a schema that extends the device schema to =
enable the provisioning of
>>  Zigbee devices [Zigbee]. =20
>> -->
>>=20
>>=20
>> 13) <!-- [rfced] Section 7.4: FYI - We have added an introductory =
sentence to the
>> URN below to match other instances in the document. Please review and =
let us
>> know if any further updates are needed.
>>=20
>> Original:
>>=20
>>  The SCIM server MUST know how to process the voucher, either =
directly or by
>>  forwarding it along to an owner process as defined in the FDO =
specification.
>>=20
>>  =
urn:ietf:params:scim:schemas:extension:fido-device-onboard:2.0:Device
>>=20
>> Current:
>>=20
>>  The SCIM server MUST know how to process the voucher, either =
directly or by
>>  forwarding it along to an owner process as defined in the FDO
>>  specification.  The extension is identified using the following =
schema URI:
>>=20
>>  =
urn:ietf:params:scim:schemas:extension:fido-device-onboard:2.0:Device
>>=20
>> -->
>>=20
>>=20
>> 14) <!--[rfced] We acknowledge this note included in the IANA =
Considerations section:
>>=20
>>  Note that the line break in URNs should be removed, as should this
>>  comment.
>>=20
>> However, without the line breaks in the URNs, the tables exceed the =
72-character
>> line limit. We have left the line breaks as is. To keep the URN lines =
unbroken,
>> we suggest reformatting to lists rather than tables.
>>=20
>> For example:
>>=20
>> URN: =
urn:iet:params:scim:schemas:extension:fido-device-onboard:2.0:Device
>> Description: FIDO Device Onboard
>> Resource Type: Device
>> Reference: RFC 9944, Section 7.4
>> -->
>>=20
>>=20
>> 15) <!-- [rfced] [BLE54]: Please review the following questions =
regarding this reference:
>>=20
>> a) We were unable to find "isRandom" mentioned in [BLE54] as seen
>> below. Should this citation be updated?
>>=20
>> Original:
>>=20
>>  isRandom:  A boolean flag taken from [BLE54]. =20
>>=20
>>=20
>> b) We also note a few instances of "BLE core specifications 5.3" =
mentioned
>> throughout this document. However, the Normative References section =
cites
>> Version 5.4. Please review and let us know if/how to update =
accordingly.
>>=20
>> For example:
>>=20
>>         "description": "The isRandom flag is taken from the BLE
>>             core specifications 5.3. If TRUE, device is using a
>>             random address.  Default value is false.",
>>=20
>>=20
>> c) Please review our updates to the text below. There are multiple =
volumes in
>> [BLE54]; it appears Section 5.4.5 is referring to Volume 1, Part A, =
Section
>> 5.4.5 of [BLE54]. Is this the correct section?
>>=20
>> Original:
>>=20
>>  For more information about the use of the IRK, see Section 5.4.5 of
>>  [BLE54].
>>=20
>> Current:
>>=20
>>  For more information about the use of the IRK, see Volume 1, Part A,
>>  Section 5.4.5 of [BLE54].
>>=20
>> -->
>>=20
>>=20
>> 16) <!-- [rfced] References:
>>=20
>> a) We note that [draft-brinckman-nipc] was replaced by =
[draft-ietf-asdf-nipc].
>> Should these remain as two separate references? Or, would you like to =
remove
>> the citation to [draft-brinckman-nipc] and only keep the=20
>> reference to [draft-ietf-asdf-nipc]?
>>=20
>>=20
>> b) [JSONSchema] also exists as an Internet-Draft:
>> =
https://secure-web.cisco.com/1NRPe2TkJoQInd1kwDqF_ZsFYhaGt5GUUMOLSUVDH0XvG=
GYa7u148O6dkJWgCFYAxNb-WWnw2fdFclMGqcYLPUohR5qcN6uLBKnvrTPKWOTw9lzU6ICLTsS=
dFRQmkooBkS6FusZOZFCau5XmiaqMwRxYvvLMpiI9UPSclYJlJ1h_QGC_sJlz4E6MFrfcLUWv7=
m7SIfriHxz9xmJUUsSfeoFrkZvWqETfwhRYTaiH5De6SjCsyquU5ACPjZpua9kMQDb4xBxiNBA=
4lfxLsixjxVZj048WSFPXyB1FxYet3VYeX7ntyWMrgO1D89g5RJsAH/https%3A%2F%2Fdatat=
racker.ietf.org%2Fdoc%2Fdraft-bhutton-json-schema%2F
>>=20
>> May we update this reference to point to the Internet-Draft?
>>=20
>>=20
>> c) We were unable to find Version 2.0 of [DPP2] "Wi-Fi Easy Connect
>> Specification". We did find Version 3.0 from 2022:
>> =
https://secure-web.cisco.com/1CHksDHJ9rnQh4fp9wVHYzG_hf2IgYZtJAKPOuzgpHWAr=
w5M4AAuPoZ0-tP9obhJpBDMBV-ERkMEfKxDxyMI3-r1VTUcfjcWyU2E5c4znlFCfkAyU79BPkD=
BW6qvj3qRuOOShcOz_FBauuSrSPYrTIGzsN0vfVJ20UmIxkjJ3-G30uoGXkrh0ia3e4NzjKA9o=
PCkU3RdYIJ8pTtEox4tpMdkcuwUDHreMBSJd2AVmD9IJ-Bck_h5YrLqIv52fL5Ch92gkiL9Eip=
IUnpZpZNi_vjYBY9j7pHDupjVb8mZUQmPKDtnfEZGV39kM4OYwIah3/https%3A%2F%2Fwww.w=
i-fi.org%2Fsystem%2Ffiles%2FWi-Fi_Easy_Connect_Specification_v3.0.pdf
>>=20
>> Should we update this reference to point to Version 3.0 of the "Wi-Fi
>> Easy Connect Specification"?
>>=20
>> Current:=20
>>=20
>>  [DPP2]     Wi-Fi Alliance, "Wi-Fi Easy Connect Specification",
>>             Version 2.0, 2020.
>>=20
>> Perhaps:
>>  [DPP3]     Wi-Fi Alliance, "Wi-Fi Easy Connect Specification",
>>             Version 3.0, 2020, =
<https://secure-web.cisco.com/1_nu1gsoR8DjRwVhBD0qNylwolO0_L3AV4NAT-byzkl2=
_5GfQmVNyAsUBV_jsYBTMDCA60Wfwnu2-rugxZsKPN7x-6sFh56ET6Wat1sdBB2Wr0cNOlispW=
o2Er4DN4DmQkuXbivcKmdBSij3rRbU0tBo8DIGgZbfzQ5KvuoFXoDNS2bnCEiEE47fZrbjcOge=
IQ60U3tIbQqPc0FwGlZm8HL49Awk3jGd3C9qBjuPVVAedcSKLenKojTH0gYh-jEZImbQK0SrQx=
tsI3e_70Iq7t5ZYCntG7YKoI8Nwvx0q3PY83kJcWsreVJ3oRcl19CwL/https%3A%2F%2Fwww.=
wi-fi.org%2Fsystem%2Ffiles%2FWi-
>>             Fi_Easy_Connect_Specification_v3.0.pdf>.
>>=20
>> -->
>>=20
>>=20
>> 17) <!-- [rfced] Appendix C: Please review the ASCII artwork that =
appears at the
>> end of this section. The submitted ASCII artwork does not render or =
match its SVG
>> equivalent. -->
>>=20
>>=20
>> 18) <!-- [rfced] Please review the "type" attribute of each =
sourcecode element
>> in the XML file to ensure correctness. If the current list of =
preferred
>> values for "type"
>> =
(https://secure-web.cisco.com/1Sg7fuEo7uRBbzR0Br0jROccGOaMOEJ_hTAxT_OepNXl=
ykk4yrVBoGgbmSybQdKUVQR-V0FhhJd79g8Z1l5uRJ_Lj8WU-nI_zVuixWesjoxmMz3ZPEnFkE=
9C-zRKzxr9Od-rg3JxE_5Js5xGPKfR1UKyLLqu9hR5RyBfOL800yts44a_7x6fkE-OPTi72WBO=
UIl_b-cLXm3MTNnjH4TDoFU3c2b5No9jBxZ5sNUezVkz6J8ULuj14XMeH6jHdCGSML9-4VAOeM=
XDKP1TZTUalVsmIcRVRGVFUmwEQkoXLoZ6jO2j8GcC--khHmNzuHqP3/https%3A%2F%2Fwww.=
rfc-editor.org%2Frpc%2Fwiki%2Fdoku.php%3Fid%3Dsourcecode-types)
>> does not contain an applicable type, then feel free to let us know.
>> Also, it is acceptable to leave the "type" attribute not set. =20
>>=20
>> In addition, review each artwork element. Specifically,
>> should any artwork element be tagged as sourcecode or another
>> element?=20
>> -->
>>=20
>>=20
>> 19) <!-- [rfced] Terminology:
>>=20
>> a) We note that the following items appear differently throughout =
this
>> document (with different quotation marks, capitalization, spacing, =
etc.).
>> Please review and let us know if any of these should be updated for
>> consistency:
>>=20
>> the device
>> the Device
>>=20
>> Device schema
>> device schema
>>=20
>> "ResourceType" schema
>>=20
>> EndpointApp schema
>> endpointApp schema=20
>> endpoint Apps extension schema
>> schema for "EndpointApp"
>>=20
>> resource type 'Device'
>> resource type, Device
>> Device resource types
>> resource "Device"
>>=20
>> 'EndpointApp' resource type
>> 'EndpointApp' resource
>> resource "EndpointApp"
>> resource "endpointApp"
>> endpointApp resource object
>>=20
>> 'deviceControl'
>> deviceControl
>>=20
>> 'telemetry'
>> telemetry
>>=20
>>=20
>> b) We note that different forms of "true" and "false" are used =
throughout this
>> document in running text. May we make these items consistent by =
updating to
>> "true" and "false" (lowercase) throughout?
>>=20
>> TRUE, True > true
>> FALSE > false
>>=20
>>=20
>> c) We note a few instances of "NOT" capitalized throughout this =
document. May
>> we make these instances lowercase (change "NOT" to "not") for =
consistency and
>> so that these do not get mistaken for a BCP 14 keyword?
>>=20
>> -->
>>=20
>>=20
>> 20) <!-- [rfced] Abbreviations:
>>=20
>> a) Per Section 3.6 of RFC 7322 ("RFC Style Guide"), abbreviations =
should be
>> expanded upon first use. Please review the items below and let us =
know if/how
>> they should be expanded:
>>=20
>> i)  How may we expand "TO2" below?
>>=20
>>  After this flow is complete, the device can then first provisionally
>>  onboard, and then later receive a trust anchor through FDO's TO2 =
process.
>>=20
>> ii) Should "AP" be expanded as "Access Point", "Authenticating =
Party", or
>> something else?
>>=20
>>  If set to TRUE, the device could be expected to move within a =
network of
>>  APs. =20
>>=20
>>=20
>> b) May we expand "RESTful" by providing a definition as follows?
>>=20
>> Original:
>>=20
>>  confirmationNumber:  An integer which some solutions require in
>>     RESTful message exchange. =20
>>=20
>> Perhaps:
>>=20
>>   confirmationNumber:  An integer that some solutions require in
>>     a RESTful message exchange (where RESTful refers to the =
Representational
>>     State Transfer (REST) architecture).
>>=20
>>=20
>> c) FYI - We have added expansions for the following abbreviations. =
Please review
>> each expansion in the document carefully to ensure correctness.
>>=20
>> Certificate Authority (CA)
>> Near Field Communication (NFC)
>> Non-IP Device Control (NIPC)
>> Universally Unique Identifier (UUID)=20
>>=20
>> -->
>>=20
>>=20
>> 21) <!-- [rfced] Please review the "Inclusive Language" portion of =
the online
>> Style Guide =
<https://secure-web.cisco.com/1C0-wbT286kNkNS1e88NTpkZNCAMKC4Lb90skQXoRyhb=
23zOMZs9CfKCJCIiG6PdI8m8yVU0YkLUE6KIIsRHTR8xpgxpqIyP-KG2H2AccNy5vgzFYL7vOa=
4QQk4AJDnWT7FS3rxLOiboH9OFJLGadjv3fLWhoC41IXm-9grgcw-zndHXZUTOBoWLf658wswf=
7infpD8-l1kC_jolUbSjbmFamm-ahgcVIXkrCc9hoHF9-eUSlU7udlJUUZ0d36_nHTSyXO_OEA=
iBfM2QHHFwtpkT5CC5VizZM8AMreIIRIBKcU4WCJbVyGTEZ4YU2RC9o/https%3A%2F%2Fwww.=
rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language>
>> and let us know if any changes are needed.  Updates of this nature =
typically
>> result in more precise language, which is helpful for readers.
>>=20
>> For example, please consider whether "native" should be updated:
>>=20
>>  SCIM clients MUST NOT specify this to describe native IP-based =
devices.
>> -->
>>=20
>>=20
>> Thank you.
>>=20
>> Kaelin Foody and Alanna Paloma
>> RFC Production Center
>>=20
>>=20
>> On Mar 11, 2026, at 11:39=E2=80=AFAM, rfc-editor@rfc-editor.org =
wrote:
>>=20
>> *****IMPORTANT*****
>>=20
>> Updated 2026/03/11
>>=20
>> RFC Author(s):
>> --------------
>>=20
>> Instructions for Completing AUTH48
>>=20
>> Your document has now entered AUTH48.  Once it has been reviewed and=20=

>> approved by you and all coauthors, it will be published as an RFC. =20=

>> If an author is no longer available, there are several remedies=20
>> available as listed in the FAQ =
(https://secure-web.cisco.com/1ZTmh19LuGuOi6DPX59eYFwq-IkorJMDi92sAx1RoPs3=
ukkGQdUCkHeyqCZvMz4z4nZa1q7498CDMTGu51gJWEgL0CpMrqSHltUBc8FDlO4rTRoi1gDyf8=
6s33hf1UrWWEfZ_0K0HK3bQKuQobB84zCaC8nEEnojca38ctSFv3Hrz3DNwrIryjA9YcgzExhS=
yVdfwrCHZSNA9go8SaUn_HMBSZ894W95R_ov5ikAFqB2SW-xwZiFWyoxFZbdTblXJw30GQZU49=
gjEyysCNx5iUSBSz4jzWhQeS4kBcGZklLNy-tADkMKuSU3Xtkx4MHhB/https%3A%2F%2Fwww.=
rfc-editor.org%2Ffaq%2F).
>>=20
>> You and you coauthors are responsible for engaging other parties=20
>> (e.g., Contributors or Working Group) as necessary before providing=20=

>> your approval.
>>=20
>> Planning your review=20
>> ---------------------
>>=20
>> Please review the following aspects of your document:
>>=20
>> *  RFC Editor questions
>>=20
>>  Please review and resolve any questions raised by the RFC Editor=20
>>  that have been included in the XML file as comments marked as=20
>>  follows:
>>=20
>>  <!-- [rfced] ... -->
>>=20
>>  These questions will also be sent in a subsequent email.
>>=20
>> *  Changes submitted by coauthors=20
>>=20
>>  Please ensure that you review any changes submitted by your=20
>>  coauthors.  We assume that if you do not speak up that you=20
>>  agree to changes submitted by your coauthors.
>>=20
>> *  Content=20
>>=20
>>  Please review the full content of the document, as this cannot=20
>>  change once the RFC is published.  Please pay particular attention =
to:
>>  - IANA considerations updates (if applicable)
>>  - contact information
>>  - references
>>=20
>> *  Copyright notices and legends
>>=20
>>  Please review the copyright notice and legends as defined in
>>  RFC 5378 and the Trust Legal Provisions=20
>>  (TLP =E2=80=93 =
https://secure-web.cisco.com/1Hbd2p7ZVbQTEg24oRuqanq63lIetXKqJxop8WMtZfKHH=
zHUxLPfVVHXqL8t9zHs11Br4IYEdNsTQcK7vqxmW31qxXydNbo44ThdImBZFFZFBQswchymuzg=
i2trZJ9qWHuhOnlD9PX9H8k93rULki2w0lK9ng7WSlvi9xfaPlsBkdaA0nVeGd1RKVa2U3eDph=
rvbXfez05MaPH23yfGBe2lkZB105rOFFFEVjgbUgmOKexZoz1hsUZcX7W4HMBkpLDH5E4fdEWg=
Uxu9HCyIOdwtoDCIYuF7v8r2AzV2zocpAR5uPvQYBBbutajKcurR76/https%3A%2F%2Ftrust=
ee.ietf.org%2Flicense-info).
>>=20
>> *  Semantic markup
>>=20
>>  Please review the markup in the XML file to ensure that elements of =20=

>>  content are correctly tagged.  For example, ensure that <sourcecode>=20=

>>  and <artwork> are set correctly.  See details at=20
>>  =
<https://secure-web.cisco.com/1KrOoPQC4GruJQ64FrK-ohYh-eqEfa-B7NDD3n-qzVBr=
B-rke0OCgSwENlzfbuLuZCK1MOmnsPrahdvbkJn9q3ZrAXaAeWlDh8BVxWKUtT7AYWYT5djp19=
DQ2GYZsIoMsaDS2zaahKCmsj64r-oy7VAtwdP17ovjWNgbCYbYOmh3CTcqiwL0Y3B5mqQyIgLy=
iXtKqftiAJU6pmjzTvjXBMpAwY-2cU-dUBT1PaNyJEQSJVCsTm-YKdi4uJzTBA9NXue_Q-5NPi=
yJwRxldTqWkYF6QyC_CviQJxPJE1KMv9qUS31sVudk0p_uSLhwyLm1G/https%3A%2F%2Fauth=
ors.ietf.org%2Frfcxml-vocabulary>.
>>=20
>> *  Formatted output
>>=20
>>  Please review the PDF, HTML, and TXT files to ensure that the=20
>>  formatted output, as generated from the markup in the XML file, is=20=

>>  reasonable.  Please note that the TXT will have formatting=20
>>  limitations compared to the PDF and HTML.
>>=20
>>=20
>> Submitting changes
>> ------------------
>>=20
>> To submit changes, please reply to this email using =E2=80=98REPLY =
ALL=E2=80=99 as all=20
>> the parties CCed on this message need to see your changes. The =
parties=20
>> include:
>>=20
>>  *  your coauthors
>>=20
>>  *  rfc-editor@rfc-editor.org (the RPC team)
>>=20
>>  *  other document participants, depending on the stream (e.g.,=20
>>     IETF Stream participants are your working group chairs, the=20
>>     responsible ADs, and the document shepherd).
>>=20
>>  *  auth48archive@rfc-editor.org, which is a new archival mailing =
list=20
>>     to preserve AUTH48 conversations; it is not an active discussion=20=

>>     list:
>>=20
>>    *  More info:
>>       =
https://secure-web.cisco.com/1BAoF0Oh2xlvAWhA-HsJoGflROu4ZXRkHWJdsrl_r553a=
IaDWS-MXAnJCxh-Fq4nqrggCqJKkiGvtl4UGOLhdcGIDXqlOiVWxG59EdZ5H7242HiCS1RIQZV=
Wm8LFhSzqc5PcsCkvQoR8_bj04njZqHqRtXTyMJoCtVDjhDrKSih2SkyeEHeCdcRgNqGjKJuUx=
2QtMMt4T5MDq6gaTqcF3rIOwzo-J9fB4AclCoN5Io6ctYhiMsuywP6sJ7hvPR4Obghe7DKaknc=
NVqlacEHAHRlAVycHLX58uU48rDnjEgLhUiFSirPES6hYbjS9jUdeg/https%3A%2F%2Fmaila=
rchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIAe6P8O4Zc=

>>=20
>>    *  The archive itself:
>>       =
https://secure-web.cisco.com/1gftLTyV4KjIC-1n3KC9xll0wLo8C64mEOSHcuL9DHCl2=
ITR4p4YUnhKKMlf-3CXfOMrZ1AomaiScJulgCvy_33uJ6ur5955eeQJdDGJT2D3_-z1LdlMRSP=
0GEot9uYxBzmUHQj7CFv54CY42hx0NDtp2l7_enhHsEwuJeuMIhRuUW4JqT_7deYZXYSIzwhEA=
HuhTQCBRLqjkvgizYWl8ZASu_yRZ7aKyuYyahzw8s3-HkTpLYF2mVi56qsGduTIIYKGc3PuJ_N=
hkCx_Qs2Ab2VdvEUOUKVJvkKwdEEdYDzApAY6Z-A69cuzb3O46k4y9/https%3A%2F%2Fmaila=
rchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F
>>=20
>>    *  Note: If only absolutely necessary, you may temporarily opt out=20=

>>       of the archiving of messages (e.g., to discuss a sensitive =
matter).
>>       If needed, please add a note at the top of the message that you=20=

>>       have dropped the address. When the discussion is concluded,=20
>>       auth48archive@rfc-editor.org will be re-added to the CC list =
and=20
>>       its addition will be noted at the top of the message.=20
>>=20
>> You may submit your changes in one of two ways:
>>=20
>> An update to the provided XML file
>> =E2=80=94 OR =E2=80=94
>> An explicit list of changes in this format
>>=20
>> Section # (or indicate Global)
>>=20
>> OLD:
>> old text
>>=20
>> NEW:
>> new text
>>=20
>> You do not need to reply with both an updated XML file and an =
explicit=20
>> list of changes, as either form is sufficient.
>>=20
>> We will ask a stream manager to review and approve any changes that =
seem
>> beyond editorial in nature, e.g., addition of new text, deletion of =
text,=20
>> and technical changes.  Information about stream managers can be =
found in=20
>> the FAQ.  Editorial changes do not require approval from a stream =
manager.
>>=20
>>=20
>> Approving for publication
>> --------------------------
>>=20
>> To approve your RFC for publication, please reply to this email =
stating
>> that you approve this RFC for publication.  Please use =E2=80=98REPLY =
ALL=E2=80=99,
>> as all the parties CCed on this message need to see your approval.
>>=20
>>=20
>> Files=20
>> -----
>>=20
>> The files are available here:
>>  =
https://secure-web.cisco.com/1szltiMvqunDtK3CKz7X8qmowlaRGbnFFu4Dz_iqVMtOS=
D38hZ1y1PhwzjuH_QKMeqwLbx7s8iWPIJzZE1KqNQLCYbdXjeAh6P6BFMNjpiRKEMkS7qYQ_X-=
7DZhrbDddwKfUYOH9i98nAurOJRqB4HSP-xlEfmymG_M6Z60UOjZaSVrkgOnV01_hEmjy0YYmu=
9UFjNy27SgNcn-8j9bAbRZVgfybTW1d7Dg1ICxnCPOlhyuArIjAXAoR29av2HS8Lb8NRts_ICS=
mZQJxT0QrCu5xDJX292dMLdSqn-Xb8xHXVyJ5S4Jswn7rfHJaANwjm/https%3A%2F%2Fwww.r=
fc-editor.org%2Fauthors%2Frfc9944.xml
>>  =
https://secure-web.cisco.com/1MN4yjneRuY4Y66Fl1lQctt59apTD5PX73RojypMRqGuB=
LRNcv1lSJEidzzY51Hyo8hG4NShz3AR2EUWiR7vEHfrLPiR5Ui53dd_RuQA2jgmiC_11_kVrHE=
O7i2K5iBAo9SpXw8lEATTUzmj1h_9Y1HZ_MJlrv_RUiu_fd3oDxqhMTLG_VWafbsIVgRVrR7al=
sFvq2NNVSDdaCxZ3jkSSRdU8AqVIc7g5KA-_8S6fahiHiKGXIpdcSdSAthFl97aMQOFPYTt3ft=
mhu01Dh3RCP_-3JSRb5aLxuMjDLbFe59UY2aRb7wXP4Rg6mEp6jKd1/https%3A%2F%2Fwww.r=
fc-editor.org%2Fauthors%2Frfc9944.html
>>  =
https://secure-web.cisco.com/1wGaAVXlksoxO60gpqqPc1NVoKM33vchMXOqJH9Dh96zw=
5G8SPh0gzzEJtLlZxMeG63oaCY0ws_Mx4dBNihDlP30DFtYsFUH7b89v8e1ymulKuwwh-7NzRR=
j8ES5286hgv3M1oPo5k3l4zt_8XJml3Pwm3YM37IRY7tnsARzOifFFu49aJ3odLorjfKX8SE9b=
ZM9vuAaKtGGdMMUP58z-mFytEYxjBNpMq3fd__UNEdEkKnODV7-TqwDnwXNjeQbvPt9WnD8ZS2=
Pw1N7XM20L7y7VmB_8TafZ8p18C-ljnPQtH36F1RVQgrCjTOyUNQiB/https%3A%2F%2Fwww.r=
fc-editor.org%2Fauthors%2Frfc9944.pdf
>>  =
https://secure-web.cisco.com/1Qz18JAOLHRZxezk3Y09lP-tfe2kOOBAv_ls7hiyi_jPV=
CVO3XBdd_GjY28hFoBcLs8cjZxatBwIztzcq-JWggEPKisrmDMkIGBLvJDbckWhO8pTmJonruu=
WgeRLyPeZK9HrzqAuosn9SN-_unLzux2zsILNjwX6sDxIewTBsZliKaUkALetDq12MeoszvW_N=
wIdX08hKm5oE-LTMBippzLyMDBr1OnBucQY_BOwRa-159qrWAIjyQ2uz7sSjZ3cEu3E7-_aajk=
B6q2Pl_smtNC_63Up7QMC_Uzo2ibvukKN3gifp-TyP4U0dPQh3N0cQ/https%3A%2F%2Fwww.r=
fc-editor.org%2Fauthors%2Frfc9944.txt
>>=20
>> Diff file of the text:
>>  =
https://secure-web.cisco.com/1H5CD4WmvcVakvHo8c-sDnPRsGHoCPJODMS63Yg3GiH1d=
g4uBAFL2NFN4vLqtSHoJ5EYgofQS9U6iVPqHCP_JdJmHxLCFgNvN-Sn_Oq_joS57_B5frDXMkz=
3iRLf67FuAojZzZnLQSO1Xtyw-SAimk8SWa21xYRROEN45tfDSCrf618IS9tfRMObja7hzodjw=
cvisCvlzuM-z7JtSEs5H-w5TB_W45m9tSBCc2TwT98kT0OCznvhZ7ds_L_CErzeEVjRX8EfpX8=
gjMhxdy8iUA0FiUKKvKmyOTB3tElJrc1jSJFzK4iYmWHJlXKeKv-eK/https%3A%2F%2Fwww.r=
fc-editor.org%2Fauthors%2Frfc9944-diff.html
>>  =
https://secure-web.cisco.com/1G5tEqbUuikCIZP30Ev-rU8U5ynqlbeMRr6crfyyj2Hr2=
9_CAasBCIYvkLDDcYfph4Ok2Du_tequ3qn66gyOFdW7uTGsWqGPD4Sam9DkwBNiUVjuYGUM__e=
OUHW-Gq8JQiftlmRRdNnl4FEhN-kTKEFf3Un6hbyyknH4w_hJN8T3vrV4bCUgyh77f9KYMCSe2=
prO9ztc4o6QU9_n4RM80cXFNPV0zDPZURgaDUk08Yaf2rVBuPNwL7bKxS07RyX2S7k-KlTGret=
ip8H8TNyTTe9Ho4zySPwfj4wynqcVIWbjdmz-vcLW52YZ6qt7S7y_M/https%3A%2F%2Fwww.r=
fc-editor.org%2Fauthors%2Frfc9944-rfcdiff.html (side by side)
>>=20
>> Diff of the XML:=20
>>  =
https://secure-web.cisco.com/1pOrdb0QnSk5kekzJNcTE4XWl5byt6ggRy4GJMVKr7485=
UDpz9mgwpgzQW2dmgKMbxEG0u3GLp4XyXvdqvih-oxUbuz9UPPn_QndN2KfFNT4afhmx1JQU6l=
4NrHmQt6hzo6I1RcMxZuVcqfNOJZ3pZ1fsUAiDThiaY8nslxdwXxbF-NUqlZ_F9ehQlQ6j9Adv=
pGJKVXYnw3P4SRw6h9lCcl3EHfVj80IG9bQhNEPP-8wOvoPYA0pkm3IF5ZgQnKNsZLasamr9lN=
mhGyX1AsgfljoiqI09THcsAK267zoYgxziDfq1jYibDs50ILRBldoA/https%3A%2F%2Fwww.r=
fc-editor.org%2Fauthors%2Frfc9944-xmldiff1.html
>>=20
>>=20
>> Tracking progress
>> -----------------
>>=20
>> The details of the AUTH48 status of your document are here:
>>  =
https://secure-web.cisco.com/1kQNcsjzCZzhN-TrMuFs5BAPD1ib3EIQq0BufI1z501cx=
5jV8fUa1JV_HuJUCqIUtFd1iDItW-g3pb5Yi7TPP3LSomnu8v6TaM0yu5Fqfr3Je5vxAWL2EJR=
gfyUVk8b598viTSVohJ79UnIRs1D1cKrD3oyQxdFEOlZzTB1l3nwF6xgDSAxxlLm_vktYzDzQo=
edaP5FAfU-NZNuAYrwWf0smu9KV2kbUbS0Vr6tJ0XxAQycImvK9QdJMxiDQsdjNK3LNfUjz90F=
YdoPW-G4CkUWAK2dpwEgweNKTbLwBa7P4IdJpJY7aNFva-vo7doIoL/https%3A%2F%2Fwww.r=
fc-editor.org%2Fauth48%2Frfc9944
>>=20
>> Please let us know if you have any questions. =20
>>=20
>> Thank you for your cooperation,
>>=20
>> RFC Editor
>>=20
>> --------------------------------------
>> RFC9944 (draft-ietf-scim-device-model-18)
>>=20
>> Title            : Device Schema Extensions to the SCIM model
>> Author(s)        : M. Shahzad, H. Iqbal, E. Lear
>> WG Chair(s)      : Nancy Cam-Winget
>> Area Director(s) : Deb Cooley, Paul Wouters