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 -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
