Hi Kaelin and friends, Thanks to you and the team for an excellent scrub.
Please see below regarding your suggestions: > On 11 Mar 2026, at 19:41, [email protected] wrote: > > Authors, > > While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are also in the source file. > > 1) <!-- [rfced] Please note that the title of the document has been updated as > follows: > > Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC > Style Guide"). Please review. > > Original: > > Device Schema Extensions to the SCIM model > > Current: > > Device Schema Extensions to the System for Cross-Domain Identity > Management (SCIM) Model > > --> Agree. > > > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > the title) for use on [smushed url] Provisioning, CRUD. > > > 3) <!-- [rfced] In the text below, we have updated "JSON Schema" to "JSON > Schemas" (plural) > and "OpenAPI" to "OpenAPI versions" (for consistency with the first sentence). > Please review to confirm these changes are accurate. > > Original: > > 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... > > Current: > > 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... > > --> > Agree. > > 4) <!-- [rfced] Could the citations below be updated as follows for clarity? > We ask because it appears that attribute characteristics are defined > in Section 2.2 of RFC 7643, and that attribute datatypes are defined > in Section 2.3 of RFC 7643. > > Original: > > Attributes defined in the device core schema and extensions comprise > characteristics and SCIM datatypes defined in Sections 2.2 and 2.3 of > [RFC7643]. > > Perhaps: > > 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]). > > --> > That’s fine. > > 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. > > Original: > > 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. > > Perhaps: > > 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. > > --> That’s fine. > > > 6) <!-- [rfced] To make this definition more concise, may we combine the > second > and fifth sentences as follows? > > Original: > > 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. > When present, this attribute may be used as described in [RFC8520]. > This attribute is case sensitive and returned by default. > > Perhaps: > > 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]. > The mudUrl value is case sensitive and not unique. > > —> Agree. > 7) <!-- [rfced] Please review the following questions regarding the notation > used > in Tables 1 through 8: > > 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: > > R: ReadOnly > RO: ReadOnly I would go for RO for clarity. > > b) We note these notations also appear with and without a space. Please review > and let us know how to update for consistency: > > WO: Write Only > WO: WriteOnly No space. > > c) We note that "Manuf" is not included in Table 2. May we remove it from the > legend listed directly after the table? > > Manuf: Manufacturer > > --> > Yes. Good catch! > > 8) <!-- [rfced] May we adjust these definitions below in order to clarify what > list items "not" refers to? > > Original: > > 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. > > Perhaps: > > 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. > > --> > We would like to leave this text unresolved for this very moment, as we have discovered a small wrinkle in the text in operation. I’ll raise that in a separate email once we’ve resolved the rest of these issues. > > 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 > clarify what list items "not" refers to? > > Original: > > 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. > > Perhaps: > > rootCA: A base64-encoded string as described in Section 4 of > [RFC4648]. It is a trust anchor certificate applicable for > certificates used for client application access. > The object is not required. It is singular, case sensitive, and > read/write. > > —> > That’s seems to do the job ;-) > 10) <!-- [rfced] May we adjust the text below as follows to make these list > items > more parallel and readable? > > Original: > > SCIM provides various extension schemas, their attributes, JSON > representation, and example object. > > Perhaps: > > SCIM provides various extension schemas and their attributes, along with > JSON > representations and example objects. > > --> > > Yes. > 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. > > Current: > > ii. The pairingJustWorks extension is identified using the > following schema URI: > > urn:ietf:params:scim:schemas:extension:pairingJustWorks:2.0:Device > > 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. > > iii. The pairingPassKey extension is identified using the following > schema URI: > > urn:ietf:params:scim:schemas:extension:pairingPassKey:2.0:Device > > 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: > > ^[0-9]{6}$ > > Perhaps: > > pairingJustWorks extension: Identified using the following schema > URI: > > urn:ietf:params:scim:schemas:extension:pairingJustWorks:2.0:Device > > 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. > > pairingPassKey extension: Identified using the following > schema URI: > > urn:ietf:params:scim:schemas:extension:pairingPassKey:2.0:Device > > 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: > > ^[0-9]{6}$ > --> > I think that looks okay. > > 12) <!-- [rfced] How may we make the two instances below complete sentences in > order to provide more context for the reader? > > Original: > > 7.2. Wi-Fi Easy Connect Extension > > A schema that extends the device schema to enable Wi-Fi Easy Connect > (otherwise known as Device Provisioning Protocol or DPP). > > 7.5. Zigbee Extension > > A schema that extends the device schema to enable the provisioning of > Zigbee devices [Zigbee]. > > Perhaps: > > 7.2. Wi-Fi Easy Connect Extension > > This section describes a schema that extends the device schema to enable > Wi-Fi Easy Connect > (otherwise known as Device Provisioning Protocol (DPP)). > > 7.5. Zigbee Extension > > This section describes a schema that extends the device schema to enable > the provisioning of > Zigbee devices [Zigbee]. > --> > That’s fine. > > 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. > > Original: > > 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. > > urn:ietf:params:scim:schemas:extension:fido-device-onboard:2.0:Device > > Current: > > 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: > > urn:ietf:params:scim:schemas:extension:fido-device-onboard:2.0:Device > > --> > > Looks good. Keep this up and we may need to add you as authors ;-) > 14) <!--[rfced] We acknowledge this note included in the IANA Considerations > section: > > Note that the line break in URNs should be removed, as should this > comment. > > 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. The note is for the reader, not the RFC editor ;-) > > For example: > > 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 > --> > > But that’s fine. > 15) <!-- [rfced] [BLE54]: Please review the following questions regarding > this reference: > > a) We were unable to find "isRandom" mentioned in [BLE54] as seen > below. Should this citation be updated? > > Original: > > isRandom: A boolean flag taken from [BLE54]. > > I’m checking on this. > 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. > > For example: > > "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.", > > > 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? > > Original: > > For more information about the use of the IRK, see Section 5.4.5 of > [BLE54]. > > Current: > > For more information about the use of the IRK, see Volume 1, Part A, > Section 5.4.5 of [BLE54]. > > --> > Yes. > > 16) <!-- [rfced] References: > > 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 > reference to [draft-ietf-asdf-nipc]? Yes. > > > b) [JSONSchema] also exists as an Internet-Draft: > May we update this reference to point to the Internet-Draft? No. This one can be left as is. We’re just a little too early. > > > 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_hf2IgYZtJAKPOuzgpHWArw5M4AAuPoZ0-tP9obhJpBDMBV-ERkMEfKxDxyMI3-r1VTUcfjcWyU2E5c4znlFCfkAyU79BPkDBW6qvj3qRuOOShcOz_FBauuSrSPYrTIGzsN0vfVJ20UmIxkjJ3-G30uoGXkrh0ia3e4NzjKA9oPCkU3RdYIJ8pTtEox4tpMdkcuwUDHreMBSJd2AVmD9IJ-Bck_h5YrLqIv52fL5Ch92gkiL9EipIUnpZpZNi_vjYBY9j7pHDupjVb8mZUQmPKDtnfEZGV39kM4OYwIah3/https%3A%2F%2Fwww.wi-fi.org%2Fsystem%2Ffiles%2FWi-Fi_Easy_Connect_Specification_v3.0.pdf > > Should we update this reference to point to Version 3.0 of the "Wi-Fi > Easy Connect Specification"? > > Current: > > [DPP2] Wi-Fi Alliance, "Wi-Fi Easy Connect Specification", > Version 2.0, 2020. > > Perhaps: > [DPP3] Wi-Fi Alliance, "Wi-Fi Easy Connect Specification", > Version 3.0, 2020, ... > > —> > Yes. > > 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. --> It looked like a maze that had collapsed! ;-) > > > 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_OepNXlykk4yrVBoGgbmSybQdKUVQR-V0FhhJd79g8Z1l5uRJ_Lj8WU-nI_zVuixWesjoxmMz3ZPEnFkE9C-zRKzxr9Od-rg3JxE_5Js5xGPKfR1UKyLLqu9hR5RyBfOL800yts44a_7x6fkE-OPTi72WBOUIl_b-cLXm3MTNnjH4TDoFU3c2b5No9jBxZ5sNUezVkz6J8ULuj14XMeH6jHdCGSML9-4VAOeMXDKP1TZTUalVsmIcRVRGVFUmwEQkoXLoZ6jO2j8GcC--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. > > In addition, review each artwork element. Specifically, > should any artwork element be tagged as sourcecode or another > element? > --> > Will do. > > 19) <!-- [rfced] Terminology: > > 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: > > the device > the Device Should be “the device” (lower case). > > Device schema > device schema Lower case. > > "ResourceType" schema This one is a nightmare from 7643 and needs to be left as is. > > EndpointApp schema > endpointApp schema This one is a nightmare of our own making, and all instances should be EndPointApp. > endpoint Apps extension schema And just to make your head spin, this one should be endpointAppsExt. > schema for "EndpointApp" > > resource type 'Device' > resource type, Device Probably no quotes? > Device resource types > resource "Device" Device resource types. > > 'EndpointApp' resource type > 'EndpointApp' resource > resource "EndpointApp" > resource "endpointApp" Should be EndpointApp > endpointApp resource object EndointApp resource object. > > 'deviceControl' > deviceControl No quotes. > > 'telemetry' > telemetry > No quotes > > 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? > > TRUE, True > true > FALSE > false > “true” in descriptive text, but this may require reflowing some of the JSON (e.g., “active”). > > 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? > > --> I see two instances. Yes. Go ahead. But one of those instances requires some additional attention as discussed above. > > > 20) <!-- [rfced] Abbreviations: > > 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: > > i) How may we expand "TO2" below? > > After this flow is complete, the device can then first provisionally > onboard, and then later receive a trust anchor through FDO's TO2 process. Transfer Ownership Protocol 2 > > ii) Should "AP" be expanded as "Access Point", "Authenticating Party", or > something else? Access point. > > If set to TRUE, the device could be expected to move within a network of > APs. > > > b) May we expand "RESTful" by providing a definition as follows? > > Original: > > confirmationNumber: An integer which some solutions require in > RESTful message exchange. > > Perhaps: > > confirmationNumber: An integer that some solutions require in > a RESTful message exchange (where RESTful refers to the Representational > State Transfer (REST) architecture). While I leave this to the RPC, might I suggest that RESTful now be consider one of those industry terms of art that doesn’t require expansion? > > > c) FYI - We have added expansions for the following abbreviations. Please > review > each expansion in the document carefully to ensure correctness. > > Certificate Authority (CA) > Near Field Communication (NFC) > Non-IP Device Control (NIPC) > Universally Unique Identifier (UUID) > > --> > Very good. > > 21) <!-- [rfced] Please review the "Inclusive Language" portion of the online > Style Guide > <https://secure-web.cisco.com/1C0-wbT286kNkNS1e88NTpkZNCAMKC4Lb90skQXoRyhb23zOMZs9CfKCJCIiG6PdI8m8yVU0YkLUE6KIIsRHTR8xpgxpqIyP-KG2H2AccNy5vgzFYL7vOa4QQk4AJDnWT7FS3rxLOiboH9OFJLGadjv3fLWhoC41IXm-9grgcw-zndHXZUTOBoWLf658wswf7infpD8-l1kC_jolUbSjbmFamm-ahgcVIXkrCc9hoHF9-eUSlU7udlJUUZ0d36_nHTSyXO_OEAiBfM2QHHFwtpkT5CC5VizZM8AMreIIRIBKcU4WCJbVyGTEZ4YU2RC9o/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. > > For example, please consider whether "native" should be updated: > > SCIM clients MUST NOT specify this to describe native IP-based devices. > --> > > Let’s just drop that sentence. It’s redundant. Ok. I will send a 3rd email on two open points we found later today. Eliot
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
