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

[Muhammad Shahzad <[e-mail]>]

Hi All,

I approve this. Thank you

--
Muhammad Shahzad

On Mon, May 4, 2026, 8:38 AM Kaelin Foody <[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]> 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]>
> 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]> 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]> 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]> 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]>
> 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]> 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
> >>
> >
>
>