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

[Kaelin Foody <[e-mail]>]

Hi Amanda,

We have reviewed the updates and they look great. 

Thank you for all of your help with this document and for resolving these items.

All the best,

Kaelin Foody
RFC Production Center

> On May 5, 2026, at 8:16 PM, Amanda Baber via RT <[e-mail]> wrote:
> 
> Hi all,
> 
> We've added these entries to the SCIM Server-Related Schema URIs registry:
> 
> Schema URI: urn:ietf:params:scim:schemas:extension:pairingNull:2.0:Device
> Name: Pairing Null
> Reference: [RFC-ietf-scim-device-model-18, Section 7.1.3]
> 
> Schema URI: urn:ietf:params:scim:schemas:extension:zigbee:2.0:Device
> Name: Zigbee
> Reference: [RFC-ietf-scim-device-model-18, Section 7.5]
> 
> Please see
> https://www.iana.org/assignments/scim
> 
> thanks,
> Amanda
> 
> On Tue May 05 23:29:10 2026, [e-mail] wrote:
>> Approve
>> 
>> Phil
>> [e-mail]
>> 
>> 
>> 
>> 
>> 
>> 
>>> On May 5, 2026, at 4:06 PM, Amanda Baber via RT <iana-matrix-
>>> [e-mail]> wrote:
>>> 
>>> Hi Phil, Paulo (multiple parties in cc),
>>> 
>>> IANA has received a request from the RFC Editor (see below) to add
>>> two entries to the SCIM Server-Related Schema URIs registry for
>>> draft-ietf-scim-device-model during AUTH48. As the designated
>>> experts, can you approve these registrations?
>>> 
>>> We understand that if the first response we receive is an approval,
>>> we can go ahead with the registrations, unless we're asked to wait
>>> for the second expert.
>>> 
>>> thanks,
>>> 
>>> Amanda Baber
>>> IANA
>>> 
>>> =====
>>> 
>>> Hi IANA,
>>> 
>>> Please make the following updates to the "SCIM Server-Related Schema
>>> URIs" registry at
>>> <https://www.iana.org/assignments/scim/scim.xhtml#server-related>
>>> to match the edited document at <https://www.rfc-
>>> editor.org/authors/rfc9944.html#name-device-schema-extensions>.
>>> 
>>> 1) Please add the following two entries to the registry:
>>> 
>>> Schema URI:
>>> urn:ietf:params:scim:schemas:extension:pairingNull:2.0:Device
>>> Name: Pairing Null
>>> Reference: RFC 9944, Section 7.1.3
>>> 
>>> Schema URI: urn:ietf:params:scim:schemas:extension:zigbee:2.0:Device
>>> Name: Zigbee
>>> Reference: RFC 9944, Section 7.5
>>> 
>>> 2) Update "Out of Band" to "Out-of-Band”:
>>> 
>>> OLD:
>>> Out of Band Pairing for BLE
>>> 
>>> NEW:
>>> Out-of-Band Pairing for BLE
>>> 
>>> 3) Update "Wi-fi" to "Wi-Fi":
>>> 
>>> OLD:
>>> Wi-fi Easy Connect
>>> 
>>> NEW:
>>> Wi-Fi Easy Connect
>>> 
>>> Please let us know if you have any questions and thanks in advance
>>> for your help.
>>> 
>>> All best,
>>> 
>>> Kaelin Foody
>>> RFC Production Center
>>> 
>>>> On May 4, 2026, at 9:05 AM, Deb Cooley <[e-mail]> wrote:
>>>> 
>>>> I approve.
>>>> 
>>>> Deb
>>>> 
>>>> On Mon, May 4, 2026 at 8:38 AM Kaelin Foody <[e-mail]-
>>>> editor.org> 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]-
>>>>>> editor.org> 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]-
>>>>>>> editor.org> 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]-
>>>>>>>>> editor.org> 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
>>>>>> 
>>>>> 
>>>> 
>>> 
>