Thanks very much, Kaelin. I’ll be working on this tomorrow.
Eliot > On 17 Mar 2026, at 20:54, Kaelin Foody <[email protected]> wrote: > > Eliot, all, > > Thank you for sending along that updated XML file. > > We have a few additional notes and questions regarding this updated file (see > below) -- but please feel free to proceed with addressing the previous > questions in this email thread as well. > > a) Since this document has been updated to use line wrapping per RFC 8792, > please let us know where to cite RFC 8792 and include a note about line > wrapping (see the appendices of RFCs 9891 and 9834 for examples of this). > > b) The following lines in the updated JSON are too long. Kindly review and > update the lines below so that they fit within the 69-character line limit > for sourcecode. > > From A.3: of the CA certificate.”, > From A.3: dnsName.”, > From A.4: "description": "Identity Resolving Key (IRK), which is unique \ > for every device. It is used to resolve a random address. This value \ > From A.5: / Device Provisioning Protocol (DPP).”, > From A.8: "description": "The 64-bit Extended Unique Identifier (EUI-64) \ > > c) We note that some of the line wrapping in the updated JSON has > inconsistent line breaks, spacing, indentation, etc. Please review and let us > know if any updates are needed here or elsewhere. We’ve included a few > examples below: > > Section A.4: A few trailing periods in the “descriptions” > Section A.9: A line break before the closing quote in 'EndpointApp\ > > > — FILES (please refresh): — > > The updated files have been posted here: > https://www.rfc-editor.org/authors/rfc9944.txt > https://www.rfc-editor.org/authors/rfc9944.pdf > https://www.rfc-editor.org/authors/rfc9944.html > https://www.rfc-editor.org/authors/rfc9944.xml > > Diff files showing changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9944-auth48diff.html > https://www.rfc-editor.org/authors/rfc9944-auth48rfcdiff.html (side by side) > > Diff files showing all changes: > https://www.rfc-editor.org/authors/rfc9944-diff.html > https://www.rfc-editor.org/authors/rfc9944-rfcdiff.html (side by side) > > The AUTH48 status page for this document is available here: > https://www.rfc-editor.org/auth48/rfc9944 > > > Thank you, > > Kaelin Foody > RFC Production Center > > >> On Mar 15, 2026, at 7:13 AM, Eliot Lear <[email protected]> wrote: >> >> Hi Kaelin, >> >> Please see the attached XML file. I have reflowed the JSON in accordance >> with RFC 8792. At the moment, this is the only change. We have others >> queued, but since this was a big one. A few notes: >> >> • I had to do this from my own toolchain. That meant that I went back to >> the draft markdown file to do the reflow, using Carsten’s ~~~json feature to >> get it right. >> • This means that I had to backport the editorial changes you made in the >> JSON. I think I got all of them but one, which was “READ-ONLY” => “READ >> ONLY”. I believe the original is correct in this case. >> • I have repaired the last diagram. However, you may wish to review the >> earlier XML file with the tools team, since what we handed you after IESG >> approval had since been damaged. >> >> Could you please do a sanity pass over the attached? If it looks good to >> you, we can address the other remaining points. >> >> Thanks for your efforts. Sorry for the inconvenience.Eliot >> >>> On 13 Mar 2026, at 17:24, Kaelin Foody <[email protected]> wrote: >>> >>> Hi Eliot, all, >>> >>> Thanks for your reply. >>> >>> 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 AM, Eliot Lear <[email protected]> >>>> wrote: >>>> >>>> Hello RFC Editor and thanks for your efforts. >>>> >>>> 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? >>>> >>>> Eliot >>>> >>>>> 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 >>>>> >>>>> --> >>>>> >>>>> >>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in >>>>> the title) for use on >>>>> https://secure-web.cisco.com/1PPb7iv5yqbTuUJm-V3VX5WNLACWX6bTxg1xViQShhKe4erOXftZkZO31gWpaQ35KyFJ5dlGheldlVukVzD4tVLNPGMpbs7JwcabledoVGPxduQ3gapB0Snpfd7AClpcTlkgxhvhd_VgGZ5DYTDtyyheJoSXU8e9MNuTzgMMKVORG0Egx1seg0tmWEJ0X95er0xCHeVN6dPn3WUceHKZfR1aNRJPl57lIXc3zA-p7s9K9kgQcdgqW_j5o7lRCxLO84rn2KZGlSWABBdGPSm7NFwZXnbVVI6yYRtEWErQhubhjkRfK2k9qbTqF-5EghGec/https%3A%2F%2Fwww.rfc-editor.org%2Fsearch >>>>> --> >>>>> >>>>> >>>>> 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... >>>>> >>>>> --> >>>>> >>>>> >>>>> 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]). >>>>> >>>>> --> >>>>> >>>>> >>>>> 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. >>>>> >>>>> --> >>>>> >>>>> >>>>> 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. >>>>> >>>>> --> >>>>> >>>>> >>>>> 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 >>>>> >>>>> 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 >>>>> >>>>> 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 >>>>> >>>>> --> >>>>> >>>>> >>>>> 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. >>>>> >>>>> --> >>>>> >>>>> >>>>> 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. >>>>> >>>>> --> >>>>> >>>>> >>>>> 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. >>>>> >>>>> --> >>>>> >>>>> >>>>> 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}$ >>>>> --> >>>>> >>>>> >>>>> 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]. >>>>> --> >>>>> >>>>> >>>>> 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 >>>>> >>>>> --> >>>>> >>>>> >>>>> 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. >>>>> >>>>> 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 >>>>> --> >>>>> >>>>> >>>>> 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]. >>>>> >>>>> >>>>> 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]. >>>>> >>>>> --> >>>>> >>>>> >>>>> 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]? >>>>> >>>>> >>>>> b) [JSONSchema] also exists as an Internet-Draft: >>>>> https://secure-web.cisco.com/1NRPe2TkJoQInd1kwDqF_ZsFYhaGt5GUUMOLSUVDH0XvGGYa7u148O6dkJWgCFYAxNb-WWnw2fdFclMGqcYLPUohR5qcN6uLBKnvrTPKWOTw9lzU6ICLTsSdFRQmkooBkS6FusZOZFCau5XmiaqMwRxYvvLMpiI9UPSclYJlJ1h_QGC_sJlz4E6MFrfcLUWv7m7SIfriHxz9xmJUUsSfeoFrkZvWqETfwhRYTaiH5De6SjCsyquU5ACPjZpua9kMQDb4xBxiNBA4lfxLsixjxVZj048WSFPXyB1FxYet3VYeX7ntyWMrgO1D89g5RJsAH/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-bhutton-json-schema%2F >>>>> >>>>> May we update this reference to point to the Internet-Draft? >>>>> >>>>> >>>>> 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, >>>>> <https://secure-web.cisco.com/1_nu1gsoR8DjRwVhBD0qNylwolO0_L3AV4NAT-byzkl2_5GfQmVNyAsUBV_jsYBTMDCA60Wfwnu2-rugxZsKPN7x-6sFh56ET6Wat1sdBB2Wr0cNOlispWo2Er4DN4DmQkuXbivcKmdBSij3rRbU0tBo8DIGgZbfzQ5KvuoFXoDNS2bnCEiEE47fZrbjcOgeIQ60U3tIbQqPc0FwGlZm8HL49Awk3jGd3C9qBjuPVVAedcSKLenKojTH0gYh-jEZImbQK0SrQxtsI3e_70Iq7t5ZYCntG7YKoI8Nwvx0q3PY83kJcWsreVJ3oRcl19CwL/https%3A%2F%2Fwww.wi-fi.org%2Fsystem%2Ffiles%2FWi- >>>>> Fi_Easy_Connect_Specification_v3.0.pdf>. >>>>> >>>>> --> >>>>> >>>>> >>>>> 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. --> >>>>> >>>>> >>>>> 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? >>>>> --> >>>>> >>>>> >>>>> 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 >>>>> >>>>> Device schema >>>>> device schema >>>>> >>>>> "ResourceType" schema >>>>> >>>>> EndpointApp schema >>>>> endpointApp schema >>>>> endpoint Apps extension schema >>>>> schema for "EndpointApp" >>>>> >>>>> resource type 'Device' >>>>> resource type, Device >>>>> Device resource types >>>>> resource "Device" >>>>> >>>>> 'EndpointApp' resource type >>>>> 'EndpointApp' resource >>>>> resource "EndpointApp" >>>>> resource "endpointApp" >>>>> endpointApp resource object >>>>> >>>>> 'deviceControl' >>>>> deviceControl >>>>> >>>>> 'telemetry' >>>>> telemetry >>>>> >>>>> >>>>> 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 >>>>> >>>>> >>>>> 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) <!-- [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. >>>>> >>>>> ii) Should "AP" be expanded as "Access Point", "Authenticating Party", or >>>>> something else? >>>>> >>>>> 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). >>>>> >>>>> >>>>> 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) >>>>> >>>>> --> >>>>> >>>>> >>>>> 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. >>>>> --> >>>>> >>>>> >>>>> Thank you. >>>>> >>>>> Kaelin Foody and Alanna Paloma >>>>> RFC Production Center >>>>> >>>>> >>>>> On Mar 11, 2026, at 11:39 AM, [email protected] wrote: >>>>> >>>>> *****IMPORTANT***** >>>>> >>>>> Updated 2026/03/11 >>>>> >>>>> RFC Author(s): >>>>> -------------- >>>>> >>>>> Instructions for Completing AUTH48 >>>>> >>>>> Your document has now entered AUTH48. Once it has been reviewed and >>>>> approved by you and all coauthors, it will be published as an RFC. >>>>> If an author is no longer available, there are several remedies >>>>> available as listed in the FAQ >>>>> (https://secure-web.cisco.com/1ZTmh19LuGuOi6DPX59eYFwq-IkorJMDi92sAx1RoPs3ukkGQdUCkHeyqCZvMz4z4nZa1q7498CDMTGu51gJWEgL0CpMrqSHltUBc8FDlO4rTRoi1gDyf86s33hf1UrWWEfZ_0K0HK3bQKuQobB84zCaC8nEEnojca38ctSFv3Hrz3DNwrIryjA9YcgzExhSyVdfwrCHZSNA9go8SaUn_HMBSZ894W95R_ov5ikAFqB2SW-xwZiFWyoxFZbdTblXJw30GQZU49gjEyysCNx5iUSBSz4jzWhQeS4kBcGZklLNy-tADkMKuSU3Xtkx4MHhB/https%3A%2F%2Fwww.rfc-editor.org%2Ffaq%2F). >>>>> >>>>> You and you coauthors are responsible for engaging other parties >>>>> (e.g., Contributors or Working Group) as necessary before providing >>>>> your approval. >>>>> >>>>> Planning your review >>>>> --------------------- >>>>> >>>>> Please review the following aspects of your document: >>>>> >>>>> * RFC Editor questions >>>>> >>>>> Please review and resolve any questions raised by the RFC Editor >>>>> that have been included in the XML file as comments marked as >>>>> follows: >>>>> >>>>> <!-- [rfced] ... --> >>>>> >>>>> These questions will also be sent in a subsequent email. >>>>> >>>>> * Changes submitted by coauthors >>>>> >>>>> Please ensure that you review any changes submitted by your >>>>> coauthors. We assume that if you do not speak up that you >>>>> agree to changes submitted by your coauthors. >>>>> >>>>> * Content >>>>> >>>>> Please review the full content of the document, as this cannot >>>>> change once the RFC is published. Please pay particular attention to: >>>>> - IANA considerations updates (if applicable) >>>>> - contact information >>>>> - references >>>>> >>>>> * Copyright notices and legends >>>>> >>>>> Please review the copyright notice and legends as defined in >>>>> RFC 5378 and the Trust Legal Provisions >>>>> (TLP – >>>>> https://secure-web.cisco.com/1Hbd2p7ZVbQTEg24oRuqanq63lIetXKqJxop8WMtZfKHHzHUxLPfVVHXqL8t9zHs11Br4IYEdNsTQcK7vqxmW31qxXydNbo44ThdImBZFFZFBQswchymuzgi2trZJ9qWHuhOnlD9PX9H8k93rULki2w0lK9ng7WSlvi9xfaPlsBkdaA0nVeGd1RKVa2U3eDphrvbXfez05MaPH23yfGBe2lkZB105rOFFFEVjgbUgmOKexZoz1hsUZcX7W4HMBkpLDH5E4fdEWgUxu9HCyIOdwtoDCIYuF7v8r2AzV2zocpAR5uPvQYBBbutajKcurR76/https%3A%2F%2Ftrustee.ietf.org%2Flicense-info). >>>>> >>>>> * Semantic markup >>>>> >>>>> Please review the markup in the XML file to ensure that elements of >>>>> content are correctly tagged. For example, ensure that <sourcecode> >>>>> and <artwork> are set correctly. See details at >>>>> <https://secure-web.cisco.com/1KrOoPQC4GruJQ64FrK-ohYh-eqEfa-B7NDD3n-qzVBrB-rke0OCgSwENlzfbuLuZCK1MOmnsPrahdvbkJn9q3ZrAXaAeWlDh8BVxWKUtT7AYWYT5djp19DQ2GYZsIoMsaDS2zaahKCmsj64r-oy7VAtwdP17ovjWNgbCYbYOmh3CTcqiwL0Y3B5mqQyIgLyiXtKqftiAJU6pmjzTvjXBMpAwY-2cU-dUBT1PaNyJEQSJVCsTm-YKdi4uJzTBA9NXue_Q-5NPiyJwRxldTqWkYF6QyC_CviQJxPJE1KMv9qUS31sVudk0p_uSLhwyLm1G/https%3A%2F%2Fauthors.ietf.org%2Frfcxml-vocabulary>. >>>>> >>>>> * Formatted output >>>>> >>>>> Please review the PDF, HTML, and TXT files to ensure that the >>>>> formatted output, as generated from the markup in the XML file, is >>>>> reasonable. Please note that the TXT will have formatting >>>>> limitations compared to the PDF and HTML. >>>>> >>>>> >>>>> Submitting changes >>>>> ------------------ >>>>> >>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all >>>>> the parties CCed on this message need to see your changes. The parties >>>>> include: >>>>> >>>>> * your coauthors >>>>> >>>>> * [email protected] (the RPC team) >>>>> >>>>> * other document participants, depending on the stream (e.g., >>>>> IETF Stream participants are your working group chairs, the >>>>> responsible ADs, and the document shepherd). >>>>> >>>>> * [email protected], which is a new archival mailing list >>>>> to preserve AUTH48 conversations; it is not an active discussion >>>>> list: >>>>> >>>>> * More info: >>>>> >>>>> https://secure-web.cisco.com/1BAoF0Oh2xlvAWhA-HsJoGflROu4ZXRkHWJdsrl_r553aIaDWS-MXAnJCxh-Fq4nqrggCqJKkiGvtl4UGOLhdcGIDXqlOiVWxG59EdZ5H7242HiCS1RIQZVWm8LFhSzqc5PcsCkvQoR8_bj04njZqHqRtXTyMJoCtVDjhDrKSih2SkyeEHeCdcRgNqGjKJuUx2QtMMt4T5MDq6gaTqcF3rIOwzo-J9fB4AclCoN5Io6ctYhiMsuywP6sJ7hvPR4Obghe7DKakncNVqlacEHAHRlAVycHLX58uU48rDnjEgLhUiFSirPES6hYbjS9jUdeg/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIAe6P8O4Zc >>>>> >>>>> * The archive itself: >>>>> >>>>> https://secure-web.cisco.com/1gftLTyV4KjIC-1n3KC9xll0wLo8C64mEOSHcuL9DHCl2ITR4p4YUnhKKMlf-3CXfOMrZ1AomaiScJulgCvy_33uJ6ur5955eeQJdDGJT2D3_-z1LdlMRSP0GEot9uYxBzmUHQj7CFv54CY42hx0NDtp2l7_enhHsEwuJeuMIhRuUW4JqT_7deYZXYSIzwhEAHuhTQCBRLqjkvgizYWl8ZASu_yRZ7aKyuYyahzw8s3-HkTpLYF2mVi56qsGduTIIYKGc3PuJ_NhkCx_Qs2Ab2VdvEUOUKVJvkKwdEEdYDzApAY6Z-A69cuzb3O46k4y9/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F >>>>> >>>>> * Note: If only absolutely necessary, you may temporarily opt out >>>>> 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 >>>>> have dropped the address. When the discussion is concluded, >>>>> [email protected] will be re-added to the CC list and >>>>> its addition will be noted at the top of the message. >>>>> >>>>> You may submit your changes in one of two ways: >>>>> >>>>> An update to the provided XML file >>>>> — OR — >>>>> An explicit list of changes in this format >>>>> >>>>> Section # (or indicate Global) >>>>> >>>>> OLD: >>>>> old text >>>>> >>>>> NEW: >>>>> new text >>>>> >>>>> You do not need to reply with both an updated XML file and an explicit >>>>> list of changes, as either form is sufficient. >>>>> >>>>> 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, >>>>> and technical changes. Information about stream managers can be found in >>>>> the FAQ. Editorial changes do not require approval from a stream manager. >>>>> >>>>> >>>>> Approving for publication >>>>> -------------------------- >>>>> >>>>> To approve your RFC for publication, please reply to this email stating >>>>> that you approve this RFC for publication. Please use ‘REPLY ALL’, >>>>> as all the parties CCed on this message need to see your approval. >>>>> >>>>> >>>>> Files >>>>> ----- >>>>> >>>>> The files are available here: >>>>> https://secure-web.cisco.com/1szltiMvqunDtK3CKz7X8qmowlaRGbnFFu4Dz_iqVMtOSD38hZ1y1PhwzjuH_QKMeqwLbx7s8iWPIJzZE1KqNQLCYbdXjeAh6P6BFMNjpiRKEMkS7qYQ_X-7DZhrbDddwKfUYOH9i98nAurOJRqB4HSP-xlEfmymG_M6Z60UOjZaSVrkgOnV01_hEmjy0YYmu9UFjNy27SgNcn-8j9bAbRZVgfybTW1d7Dg1ICxnCPOlhyuArIjAXAoR29av2HS8Lb8NRts_ICSmZQJxT0QrCu5xDJX292dMLdSqn-Xb8xHXVyJ5S4Jswn7rfHJaANwjm/https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9944.xml >>>>> https://secure-web.cisco.com/1MN4yjneRuY4Y66Fl1lQctt59apTD5PX73RojypMRqGuBLRNcv1lSJEidzzY51Hyo8hG4NShz3AR2EUWiR7vEHfrLPiR5Ui53dd_RuQA2jgmiC_11_kVrHEO7i2K5iBAo9SpXw8lEATTUzmj1h_9Y1HZ_MJlrv_RUiu_fd3oDxqhMTLG_VWafbsIVgRVrR7alsFvq2NNVSDdaCxZ3jkSSRdU8AqVIc7g5KA-_8S6fahiHiKGXIpdcSdSAthFl97aMQOFPYTt3ftmhu01Dh3RCP_-3JSRb5aLxuMjDLbFe59UY2aRb7wXP4Rg6mEp6jKd1/https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9944.html >>>>> https://secure-web.cisco.com/1wGaAVXlksoxO60gpqqPc1NVoKM33vchMXOqJH9Dh96zw5G8SPh0gzzEJtLlZxMeG63oaCY0ws_Mx4dBNihDlP30DFtYsFUH7b89v8e1ymulKuwwh-7NzRRj8ES5286hgv3M1oPo5k3l4zt_8XJml3Pwm3YM37IRY7tnsARzOifFFu49aJ3odLorjfKX8SE9bZM9vuAaKtGGdMMUP58z-mFytEYxjBNpMq3fd__UNEdEkKnODV7-TqwDnwXNjeQbvPt9WnD8ZS2Pw1N7XM20L7y7VmB_8TafZ8p18C-ljnPQtH36F1RVQgrCjTOyUNQiB/https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9944.pdf >>>>> https://secure-web.cisco.com/1Qz18JAOLHRZxezk3Y09lP-tfe2kOOBAv_ls7hiyi_jPVCVO3XBdd_GjY28hFoBcLs8cjZxatBwIztzcq-JWggEPKisrmDMkIGBLvJDbckWhO8pTmJonruuWgeRLyPeZK9HrzqAuosn9SN-_unLzux2zsILNjwX6sDxIewTBsZliKaUkALetDq12MeoszvW_NwIdX08hKm5oE-LTMBippzLyMDBr1OnBucQY_BOwRa-159qrWAIjyQ2uz7sSjZ3cEu3E7-_aajkB6q2Pl_smtNC_63Up7QMC_Uzo2ibvukKN3gifp-TyP4U0dPQh3N0cQ/https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9944.txt >>>>> >>>>> Diff file of the text: >>>>> https://secure-web.cisco.com/1H5CD4WmvcVakvHo8c-sDnPRsGHoCPJODMS63Yg3GiH1dg4uBAFL2NFN4vLqtSHoJ5EYgofQS9U6iVPqHCP_JdJmHxLCFgNvN-Sn_Oq_joS57_B5frDXMkz3iRLf67FuAojZzZnLQSO1Xtyw-SAimk8SWa21xYRROEN45tfDSCrf618IS9tfRMObja7hzodjwcvisCvlzuM-z7JtSEs5H-w5TB_W45m9tSBCc2TwT98kT0OCznvhZ7ds_L_CErzeEVjRX8EfpX8gjMhxdy8iUA0FiUKKvKmyOTB3tElJrc1jSJFzK4iYmWHJlXKeKv-eK/https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9944-diff.html >>>>> https://secure-web.cisco.com/1G5tEqbUuikCIZP30Ev-rU8U5ynqlbeMRr6crfyyj2Hr29_CAasBCIYvkLDDcYfph4Ok2Du_tequ3qn66gyOFdW7uTGsWqGPD4Sam9DkwBNiUVjuYGUM__eOUHW-Gq8JQiftlmRRdNnl4FEhN-kTKEFf3Un6hbyyknH4w_hJN8T3vrV4bCUgyh77f9KYMCSe2prO9ztc4o6QU9_n4RM80cXFNPV0zDPZURgaDUk08Yaf2rVBuPNwL7bKxS07RyX2S7k-KlTGretip8H8TNyTTe9Ho4zySPwfj4wynqcVIWbjdmz-vcLW52YZ6qt7S7y_M/https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9944-rfcdiff.html >>>>> (side by side) >>>>> >>>>> Diff of the XML: >>>>> https://secure-web.cisco.com/1pOrdb0QnSk5kekzJNcTE4XWl5byt6ggRy4GJMVKr7485UDpz9mgwpgzQW2dmgKMbxEG0u3GLp4XyXvdqvih-oxUbuz9UPPn_QndN2KfFNT4afhmx1JQU6l4NrHmQt6hzo6I1RcMxZuVcqfNOJZ3pZ1fsUAiDThiaY8nslxdwXxbF-NUqlZ_F9ehQlQ6j9AdvpGJKVXYnw3P4SRw6h9lCcl3EHfVj80IG9bQhNEPP-8wOvoPYA0pkm3IF5ZgQnKNsZLasamr9lNmhGyX1AsgfljoiqI09THcsAK267zoYgxziDfq1jYibDs50ILRBldoA/https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9944-xmldiff1.html >>>>> >>>>> >>>>> Tracking progress >>>>> ----------------- >>>>> >>>>> The details of the AUTH48 status of your document are here: >>>>> https://secure-web.cisco.com/1kQNcsjzCZzhN-TrMuFs5BAPD1ib3EIQq0BufI1z501cx5jV8fUa1JV_HuJUCqIUtFd1iDItW-g3pb5Yi7TPP3LSomnu8v6TaM0yu5Fqfr3Je5vxAWL2EJRgfyUVk8b598viTSVohJ79UnIRs1D1cKrD3oyQxdFEOlZzTB1l3nwF6xgDSAxxlLm_vktYzDzQoedaP5FAfU-NZNuAYrwWf0smu9KV2kbUbS0Vr6tJ0XxAQycImvK9QdJMxiDQsdjNK3LNfUjz90FYdoPW-G4CkUWAK2dpwEgweNKTbLwBa7P4IdJpJY7aNFva-vo7doIoL/https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9944 >>>>> >>>>> Please let us know if you have any questions. >>>>> >>>>> Thank you for your cooperation, >>>>> >>>>> RFC Editor >>>>> >>>>> -------------------------------------- >>>>> RFC9944 (draft-ietf-scim-device-model-18) >>>>> >>>>> 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 >>> >>> >> >> <rfc9944-reflowed.xml> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
