[auth48] Re: [AD] AUTH48: RFC-to-be 9944 <draft-ietf-scim-device-model-18> for your review

[Eliot Lear <[e-mail]>]

As do I.

Thank you all.

Eliot

> On 4 May 2026, at 14:42, Muhammad Shahzad <[e-mail]> wrote:
> 
> Hi All,
> 
> I approve this. Thank you
> 
> --
> Muhammad Shahzad 
> 
> On Mon, May 4, 2026, 8:38 AM Kaelin Foody <[e-mail] <mailto:[e-mail]>> wrote:
>> Hi *Deb, Eliot,
>> 
>> *Deb - We have updated the text per Eliot’s most recent reply, but it seems no further changes are desired here. Please review and let us know if the current set of updates are acceptable. Please see https://www.rfc-editor.org/authors/rfc9944-lastrfcdiff.html.
>> 
>> Eliot - We have updated the files as requested. Please review and let us know if any additional updates are needed or if you approve the RFC for publication.
>> 
>> We will request that IANA make their relevant changes after we receive all other approvals listed on the AUTH48 status page.
>> 
>> The AUTH48 status page for this document is available here:
>> https://www.rfc-editor.org/auth48/rfc9944
>> 
>> — 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 between the last and current version:
>> https://www.rfc-editor.org/authors/rfc9944-lastdiff.html
>> https://www.rfc-editor.org/authors/rfc9944-lastrfcdiff.html (side by side)
>> 
>> 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)
>> 
>> Thank you,
>> 
>> Kaelin Foody
>> RFC Production Center
>> 
>> > On Apr 27, 2026, at 2:57 AM, Eliot Lear <[e-mail] <mailto:[e-mail]>> wrote:
>> > 
>> > Ok.  I’m back, tanned, with much more knowledge of the Greek Mycenaean and Archaic periods, and raring to go.  I’ve reviewed the diffs and I want to also address Deb’s points.
>> > 
>> > First, about “read-only” and “immutable”.  This is an artifact of RFC 7643.  “Read-only” means just that.  “Immutable” means it can be written once.
>> > 
>> > Second, everywhere in the draft, the term should be “read-only” not “read only” (this is a regression).  Case can remain as is.
>> > 
>> > Finally:
>> > 
>> > 
>> > 
>> >> On 23 Apr 2026, at 06:52, Kaelin Foody <[e-mail] <mailto:[e-mail]>> wrote:
>> >> 
>> >> 
>> >>> b) Should the update below be implemented?
>> >>> 
>> >>> Appendix B.6: 
>> >>> Two additional instances of “...:Devices” (plural) appear in this section. Should these instances be updated to “:Device” (singular) as well?
>> > 
>> > 
>> > Yes, please.
>> > 
>> > Regards,
>> > 
>> > Eliot
>> > 
>> >> 
>> >> We will request that IANA make their relevant changes after we receive all other approvals listed on the AUTH48 status page.
>> >> 
>> >> All best,
>> >> 
>> >> Kaelin Foody
>> >> RFC Production Center
>> >> 
>> >>> On Apr 17, 2026, at 7:02 AM, Hassan <[e-mail] <mailto:[e-mail]>> wrote:
>> >>> 
>> >>> Hi Kaelin,
>> >>> 
>> >>> Thank you for the updates. Approved from my end.
>> >>> 
>> >>> On Tue, Apr 14, 2026 at 4:32 PM Kaelin Foody <[e-mail] <mailto:[e-mail]>> wrote:
>> >>> Hi Eliot,
>> >>> 
>> >>> Thanks for your reply and letting us know you will be out of office -- we will wait on your reply accordingly. 
>> >>> 
>> >>> We have updated the files and Section 6.3.1 as requested. Please review the two matters below at your convenience:
>> >>> 
>> >>> a) For the item below, we have removed a space from the left margin for both the “location” line (seen below) and for the “resourceType” line that follows it, to preserve original indentation. Please review this update in Appendix A.1 for correctness. 
>> >>> 
>> >>>>> Appendix A.1: 
>> >>>>> We have updated this line per item #6, but it is now one character too long. Please review and let us know where to insert a line break for the line below:
>> >>>>> 
>> >>>>>  "location": "https://example.com/v2/ResourceTypes/EndpointApps”,
>> >>>> 
>> >>>> I think you can just indent one space.
>> >>> 
>> >>> 
>> >>> b) Should the update below be implemented?
>> >>> 
>> >>>>> Appendix B.6: 
>> >>>>> Two additional instances of “...:Devices” (plural) appear in this section. Should these instances be updated to “:Device” (singular) as well?
>> >>> 
>> >>> 
>> >>> Please review the items above and let us know if there are any outstanding updates remaining.
>> >>> 
>> >>> The AUTH48 status page for this document is available here:
>> >>> https://www.rfc-editor.org/auth48/rfc9944
>> >>> 
>> >>> — 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 between the last and current version:
>> >>> https://www.rfc-editor.org/authors/rfc9944-lastdiff.html
>> >>> https://www.rfc-editor.org/authors/rfc9944-lastrfcdiff.html (side by side)
>> >>> 
>> >>> 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)
>> >>> 
>> >>> All the best,
>> >>> 
>> >>> Kaelin Foody
>> >>> RFC Production Center
>> >>> 
>> >>> On Apr 11, 2026, at 5:51 AM, Eliot Lear <[e-mail] <mailto:[e-mail]>> wrote:
>> >>>> 
>> >>>> Hi Kaelin,
>> >>>> 
>> >>>> Below are my answers.  Please be advised, I’m going on two weeks of holiday and will have a limited ability to respond or review changes.  Also see below for the one remaining other issue which is mildly substantial but hopefully not controversial.
>> >>>> 
>> >>>> 
>> >>>>> On 9 Apr 2026, at 20:23, Kaelin Foody <[e-mail] <mailto:[e-mail]>> wrote:
>> >>>>> 
>> >>>>> Hi Eliot, all,
>> >>>>> 
>> >>>>> We have updated the files as requested. These updates are best viewed here: https://www.rfc-editor.org/authors/rfc9944-lastrfcdiff.html.
>> >>>>> 
>> >>>>> A few follow-up questions regarding these updates:
>> >>>>> 
>> >>>>> a) Section 6.3.1, Table 2:
>> >>>>> We have updated this table accordingly. May we also add a value for “Imm” in the legend that appears after this table?
>> >>>>> 
>> >>>>> Perhaps:
>> >>>>> Imm = Immutable
>> >>>> 
>> >>>> Yes.
>> >>>> 
>> >>>>> 
>> >>>>> b) Section 7.6.2, Table 8: 
>> >>>>> In the “Mutable” column of this table, should the $ref attribute’s value be updated from “R” to “RO” as well (to match the updates made to devContEntEndpoint and telEntEndpoint)?
>> >>>> 
>> >>>> Yes.
>> >>>> 
>> >>>>> 
>> >>>>> c) Appendix A.1: 
>> >>>>> We have updated this line per item #6, but it is now one character too long. Please review and let us know where to insert a line break for the line below:
>> >>>>> 
>> >>>>>  "location": "https://example.com/v2/ResourceTypes/EndpointApps”,
>> >>>> 
>> >>>> I think you can just indent one space.
>> >>>> 
>> >>>>> 
>> >>>>> d) Appendix B.6: 
>> >>>>> Two additional instances of “...:Devices” (plural) appear in this section. Should these instances be updated to “:Device” (singular) as well?
>> >>>>> 
>> >>>>> We will request that IANA make their relevant changes and request AD approval after we receive your remaining updates.
>> >>>> 
>> >>>> 
>> >>>> 
>> >>>> In Section 6.3.1, we wrote:
>> >>>> 
>> >>>> OLD:
>> >>>> 
>> >>>>> subjectName:When present, a string that contains one of two names…
>> >>>> 
>> >>>> If certificateInfo is present then subjectName must be present.  Otherwise we haven’t given sufficient implementation guidance on how to identify a valid identity.  Therefore, the proposed change is:
>> >>>> 
>> >>>> NEW:
>> >>>> 
>> >>>>> subjectName:A string that contains one of two names
>> >>>> 
>> >>>> The table already indicates that subjectName is required, as does the JSON OpenAPI.
>> >>>> 
>> >>>> This got missed in earlier review because people (including myself) may have been thinking about whether the parent object was present.
>> >>>> 
>> >>>> Regards,
>> >>>> 
>> >>>> Eliot
>> >>>> 
>> >>>> 
>> >>>> 
>> >>>>> 
>> >>>>> The AUTH48 status page for this document is available here:
>> >>>>> https://www.rfc-editor.org/auth48/rfc9944
>> >>>>> 
>> >>>>> — 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 between the last and current version:
>> >>>>> https://www.rfc-editor.org/authors/rfc9944-lastdiff.html
>> >>>>> https://www.rfc-editor.org/authors/rfc9944-lastrfcdiff.html (side by side)
>> >>>>> 
>> >>>>> 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)
>> >>>>> 
>> >>>>> All best,
>> >>>>> 
>> >>>>> Kaelin Foody
>> >>>>> RFC Production Center
>> >>>>> 
>> >>>>>> On Apr 7, 2026, at 1:45 PM, Eliot Lear <[e-mail] <mailto:[e-mail]>> wrote:
>> >>>>>> 
>> >>>>>> Hi Kaelin
>> >>>>>> 
>> >>>>>> Hassan identified a number of typos and omissions in his review.  Some of these will need IANA review, as there are several entries missing.  All of these, I think, are non-controversial edits.
>> >>>>>> 
>> >>>>>> There is one exception that we will come back to after this one.  It’s not that it’s controversial, but it is a substantive change.
>> >>>>>> 
>> >>>>>> Eliot
>> >>>>>> 1. Section 7.4.1, Figure 10 (FDO Example) — schema URIs in JSON
>> >>>>>> OLD: urn:ietf:params:scim:schemas:core:2.0:Devices and urn:ietf:params:scim:schemas:extension:fido-device-onboard:2.0:Devices
>> >>>>>> NEW: urn:ietf:params:scim:schemas:core:2.0:Device and urn:ietf:params:scim:schemas:extension:fido-device-onboard:2.0:Device
>> >>>>>> 2. Appendix A.7, FDO Extension JSON Schema — id and meta.location use plural "Devices"
>> >>>>>> OLD: "id": "urn:ietf:params:scim:schemas:extension:fido-device-onboard:2.0:Devices" and "location": "...fido-device-onboard:2.0:Devices"
>> >>>>>> NEW: "id": "urn:ietf:params:scim:schemas:extension:fido-device-onboard:2.0:Device" and "location": "...fido-device-onboard:2.0:Device"
>> >>>>>> 3. Section 7.5.1, Zigbee deviceEui64Address description
>> >>>>>> OLD: "takes the same form as the deviceMACaddress"
>> >>>>>> NEW: "takes the same form as the deviceMacAddress "
>> >>>>>> 4. Section 7.6.2, description of $ref attribute
>> >>>>>> OLD: "EndointApp"
>> >>>>>> NEW: "EndpointApp"
>> >>>>>> 5. Appendix A.1, Resource Schema — EndpointApp endpoint path
>> >>>>>> OLD: "endpoint": "/EndpointApp"
>> >>>>>> NEW: "endpoint": "/EndpointApps" 6. OLD: "location": "https://example.com/v2/ResourceTypes/EndpointApp",
>> >>>>>> NEW: "location": "https://example.com/v2/ResourceTypes/EndpointApps", 7. Appendix A.3, EndpointApp Schema meta.location
>> >>>>>> OLD: "/v2/Schemas/urn:ietf:params:scim:schemas:core:2.0:Device"
>> >>>>>> NEW: "/v2/Schemas/urn:ietf:params:scim:schemas:core:2.0:EndpointApp" 8. Appendix A.4, in schema with ID "urn:ietf:params:scim:schemas:extension:pairingOOB:2.0:Device",
>> >>>>>> OLD: "description": "Passkey pairing method for BLE."
>> >>>>>> NEW: "description": "Out-of-band pairing method for BLE."
>> >>>>>> 9. Appendix A.4, BLE Extension JSON Schema — mobility type
>> >>>>>> OLD: "type": "bool"
>> >>>>>> NEW: "type": "boolean"
>> >>>>>> 10. [We’ll come back to this one]
>> >>>>>> 11. Section 6.3.1, Table 2 — clientToken Return column
>> >>>>>> OLD: Return = N
>> >>>>>> New: Return = Def
>> >>>>>> 12. Section 7.1.3, Table 3 — isRandom Required column
>> >>>>>> OLD: Req = T
>> >>>>>> NEW: Req = F
>> >>>>>> 13. Section 7.2.1, prose description of bootstrapKey
>> >>>>>> OLD: "This attribute is required, case sensitive, mutable, and returned by default."
>> >>>>>> NEW: "This attribute is required, case sensitive, write only, and never returned."
>> >>>>>> 14. Section 9.2, IANA registrations for BLE pairing method extensions (pairingNull) — missing entry
>> >>>>>> NEW:
>> >>>>>> Schema URI: urn:ietf:params:scim:schemas:extension:pairingNull:2.0:Device
>> >>>>>> Name: Pairing Null
>> >>>>>> Resource Type: Device
>> >>>>>> Reference: RFC 9944, Section 7.1.3
>> >>>>>> 15. Section 9.2, IANA registrations for Zigbee — missing entry
>> >>>>>> NEW:
>> >>>>>> Schema URI: urn:ietf:params:scim:schemas:extension:zigbee:2.0:Device
>> >>>>>> Name: Zigbee
>> >>>>>> Resource Type: Device
>> >>>>>> Reference: RFC 9944, Section 7.5
>> >>>>>> 16. Section 9.2, IANA registration for urn:ietf:params:scim:schemas:extension:endpointAppsExt:2.0:Device — Reference
>> >>>>>> OLD: RFC 9944, Section 7.1.3
>> >>>>>> NEW: RFC 9944, Section 7.6
>> >>>>>> 17. Appendix A.4, BLE Extension JSON Schema — irk mutability and returned fields
>> >>>>>> OLD: "mutability": "readWrite", "returned": "default"
>> >>>>>> NEW: "mutability": "writeOnly", "returned": "never"
>> >>>>>> 18. Appendix A.4, pairingJustWorks schema — key attribute
>> >>>>>> OLD: "required": true
>> >>>>>> NEW: "required": false
>> >>>>>> 19. Appendix A.7, FDO Extension JSON Schema — fdoVoucher mutability and returned fields
>> >>>>>> OLD: "mutability": "readWrite", "returned": "default"
>> >>>>>> NEW: "mutability": "writeOnly", "returned": "never"
>> >>>>>> 0a. Section 6.3.1, Table 2 —  clientToken
>> >>>>>> For applicationType:
>> >>>>>> OLD: Mutable = R
>> >>>>>> NEW: Mutable = RO
>> >>>>>> 20b. Section 6.2, prose description of applicationType
>> >>>>>> OLD: "The attribute is required and is not case sensitive. The attribute is readOnly and should be returned by default."
>> >>>>>> NEW: "The attribute is required and is not case sensitive. The attribute is immutable and should be returned by default."
>> >>>>>> 20c. Section 6.3.1, Table 2 — applicationType Mutable column
>> >>>>>> OLD: Mutable = R
>> >>>>>> NEW: Mutable = Imm
>> >>>>>> 21. Section 7.6.2, Table 8 — devContEntEndpoint and telEntEndpoint 
>> >>>>>> For devContEntEndpoint: 
>> >>>>>> OLD: Mutable = R
>> >>>>>> NEW: Mutable = RO
>> >>>>>> For telEntEndpoint: 
>> >>>>>> OLD: Mutable = R
>> >>>>>> NEW: Mutable = RO
>> >>>>>> 22. Section 7.6.1, prose description of deviceControlEnterpriseEndpoint
>> >>>>>> OLD: "This attribute is required, case sensitive, mutable, and returned by default."
>> >>>>>> NEW: "This attribute is required, case sensitive, read-only, and returned by default."
>> >>>>>> 23. Section 7.6.1, prose description of telemetryEnterpriseEndpoint
>> >>>>>> OLD: "This attribute is optional, case sensitive, mutable, and returned by default."
>> >>>>>> NEW: "This attribute is optional, case sensitive, read-only, and returned by default."
>> >>>>>> 24. Section 7.6.2, Table 8 — $ref
>> >>>>>> OLD: $ref row Case Exact = F
>> >>>>>> NEW: $ref row Case Exact = T
>> >>>>>> 25. Appendix A.5, DPP Extension Schema — bootstrapKey
>> >>>>>> OLD: "mutability": "readWrite", "returned": "default"
>> >>>>>> NEW: "mutability": "writeOnly", "returned": "never"
>> >>>>>> 26. [We’ll come back to this one]
>> >>>>>> 27. [deleted]
>> >>>>>> 28. Section 6.3.1, Table 2 — missing groups attribute row
>> >>>>>> OLD: (no groups row in Table 2)
>> >>>>>> NEW: Add row groups | T | F | T | RO | Def | n/a
>> >>>>>> 29. Appendix A.9, endpointAppsExt Extension Schema — $ref sub-attribute required
>> >>>>>> OLD: "required": false
>> >>>>>> NEW: "required": true
>> >>>>>> 30. Section 7.1.3, prose — incorrect cross-reference to Section 6.1
>> >>>>>> OLD: "Each extension contains the common attributes in Section 6.1."
>> >>>>>> NEW: "Each extension contains the common attributes in Section 2.1."
>> >>>>>> 
>> >>>>> 
>> >>>> 
>> >>> 
>> >>> 
>> >>> 
>> >>> -- 
>> >>> --
>> >>> Best
>> >>> Hassan Iqbal
>> >> 
>> > 
>>