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

[Eliot Lear <[e-mail]>]

Amanda,

Do you have any suggested wording we could add to help clarify things?

Eliot

> On 31 Mar 2026, at 20:06, Amanda Baber via RT <[e-mail]> wrote:
> 
> Hi,
> 
> To create a new field, IANA would need instructions from an RFC or, if they see a clear need for it (per RFC 8126, Section 2.4), the ADs. If that's not appropriate, would it make sense to add a line that mentions that the registry doesn't include a "Resource Type" field, and that this field is being included in Table 10 for the readers' information, or something along those lines? I think our concern is just that someone might read the IANA Considerations section and wonder if the registry could have been misidentified.
> 
> thanks,
> Amanda
> 
> On Fri Mar 27 18:47:42 2026, [e-mail] wrote:
>> Hi Kaelin
>> 
>> We did note this discrepancy during an IANA expert review.  My
>> recommendation is that we not change the IANA tables at this stage,
>> since that would require a full review of the core documents.  From a
>> functional standpoint, the fields in the registry are enough.
>> 
>> That having been said, if IANA wants to update these fields, I would
>> suggest that is a process that should be reviewed at least by the
>> designated experts, if not by the working group itself.
>> 
>> Eliot
>> 
>>> On 27 Mar 2026, at 19:16, Kaelin Foody <[e-mail]>
>>> wrote:
>>> 
>>> Hi IANA, authors,
>>> 
>>> We had a few questions related to the IANA Considerations section of
>>> this document (please see <https://www.rfc-
>>> editor.org/authors/rfc9944.html#name-iana-considerations>)
>>> 
>>> a) We note that Section 9.2 contains an indicator of "Resource Type:
>>> Device”.  As this seems to match the template for registrations in
>>> RFC 7643 (see below), should a “Resource Type” column be added to the
>>> “SCIM Server-Related Schema URIs” registry
>>> <https://www.iana.org/assignments/scim/scim.xhtml#server-related> (or
>>> to any other registries in the "System for Cross-domain Identity
>>> Management (SCIM) Schema URIs”
>>> <https://www.iana.org/assignments/scim/scim.xhtml> registry group)?
>>> Or should this information be cut from Section 9.2 to more closely
>>> match the current registry entries?
>>> 
>>> From RFC 7643:
>>> 
>>> Intended or Associated Resource Type: A value defining the resource
>>> type (e.g., "Device").
>>> 
>>> b) As Section 10.3.2 of RFC 7643 and the registry at
>>> <https://www.iana.org/assignments/scim/scim.xhtml#server-related> use
>>> “Schema Name” and “Name” (respectively), we will also update
>>> "Description” to “Name” in Section 9.2 of this document, unless we
>>> hear objections otherwise (note that this change will also match
>>> usage in Section 9.1, which already uses “Name”).
>>> 
>>> Thanks in advance.
>>> 
>>> All best,
>>> 
>>> Kaelin Foody
>>> RFC Production Center
>>> 
>>>> On Mar 26, 2026, at 5:28 AM, Eliot Lear <[e-mail]> wrote:
>>>> 
>>>> Kaelin,
>>>> 
>>>> Thanks.  I only have two additional comments:
>>>> 
>>>> The legends seem to take up a lot of vertical space.  Is it possible
>>>> to consolidate them into fewer lines, or is that dictated by the
>>>> style guide?
>>>> 
>>>> Could we preface Figures 3-12 with the word “Example:”?  The lack of
>>>> a clear break makes it seem a little odd.
>>>> 
>>>> Eliot
>>>> 
>>>>> On 25 Mar 2026, at 20:16, Kaelin Foody <[e-mail]-
>>>>> editor.org> wrote:
>>>>> 
>>>>> Hi Deb, Eliot, all,
>>>>> 
>>>>> Deb - Thank you for your approval. We have marked it here:
>>>>> https://www.rfc-editor.org/auth48/rfc9944.
>>>>> 
>>>>> Eliot - Thank you for your reply. We have updated the document
>>>>> according to your responses. You may find the updated files at the
>>>>> end of this email.
>>>>> 
>>>>> One additional note:
>>>>> 
>>>>>> Should pointers to BLE 5.3 be updated to 5.4 throughout?
>>>>>> 
>>>>>>> Go with 5.4.
>>>>> 
>>>>> For above, we have updated instances of BLE 5.3 to 5.4 throughout,
>>>>> but some of these changes were made in the sourcecode. Please
>>>>> carefully review these changes to ensure they are accurate (see:
>>>>> https://www.rfc-editor.org/authors/rfc9944-lastrfcdiff.html) and
>>>>> let us know if any additional changes need to be made.
>>>>> 
>>>>> Please also note that we will ask IANA to update their registries
>>>>> to match the edited document shortly.
>>>>> 
>>>>> Upon careful review, please contact us with any further updates or
>>>>> with your approval of the document in its current form.  We will
>>>>> await approvals from each party listed on the AUTH48 status page
>>>>> for this document prior to moving forward in the publication
>>>>> process.
>>>>> 
>>>>> 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 Mar 24, 2026, at 2:39 PM, Deb Cooley <[e-mail]>
>>>>>> wrote:
>>>>>> 
>>>>>> Thanks for that.  I'm glad they are employer phone numbers.  No
>>>>>> one needs more spam on their personal phones.
>>>>>> 
>>>>>> Deb
>>>>>> 
>>>>>> On Tue, Mar 24, 2026 at 12:28 PM Muhammad Shahzad
>>>>>> <[e-mail]> wrote:
>>>>>> Hi All,
>>>>>> 
>>>>>> The address currently listed for me and Hassan is good.
>>>>>> 
>>>>>> On Tue, Mar 24, 2026 at 11:44 AM Eliot Lear <[e-mail]>
>>>>>> wrote:
>>>>>> It’s a Cisco main #, and our address.  I’m okay with it.
>>>>>> Muhammed?  Hassan?
>>>>>> 
>>>>>> Eliot
>>>>>> 
>>>>>>> On 24 Mar 2026, at 12:23, Deb Cooley <[e-mail]>
>>>>>>> wrote:
>>>>>>> 
>>>>>>> Apologies, I missed the *AD note.....(both from Kaelin and
>>>>>>> Eliot).
>>>>>>> 
>>>>>>> I've checked the diff and subsequent message from Eliot pretty
>>>>>>> carefully (especially the SHOULD/MUST change) and it all appears
>>>>>>> to be fine.  I approve the changes.
>>>>>>> 
>>>>>>> I only have one comment wrt Author Addresses:  These are super
>>>>>>> specific.  In the case of the NC State authors, it appears that
>>>>>>> the address is a department address, clearly already public.  For
>>>>>>> Eliot, that is your personal address, no?  And the phone number?
>>>>>>> I haven't seen too many phone numbers on drafts/RFCs.  This is
>>>>>>> your call, but I think it would be reasonable (and mostly the
>>>>>>> norm) to remove the actual street address and phone number.
>>>>>>> 
>>>>>>> Deb
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Tue, Mar 24, 2026 at 5:52 AM Eliot Lear <[e-mail]>
>>>>>>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>> On 20 Mar 2026, at 15:32, Kaelin Foody <[e-mail]-
>>>>>>>> editor.org> wrote:
>>>>>>>> 
>>>>>>>> Hi *Deb, Eliot, all,
>>>>>>>> 
>>>>>>>> *Deb - As AD, please review the following changes to this
>>>>>>>> document.
>>>>>>>> 
>>>>>>>> You may view them in the diff here: https://www.rfc-
>>>>>>>> editor.org/authors/rfc9944-lastdiff.html.
>>>>>>>> 
>>>>>>>> There is additional context in this email thread regarding these
>>>>>>>> changes, but we have summarized them below:
>>>>>>>> 
>>>>>>>> Section 1.3: Added sentence re: line wrapping per RFC 8792.
>>>>>>>> Section 6.3.1: Updated paragraph that appears after Table 2.
>>>>>>>> Section 7.6: Removed sentence in first paragraph (per inclusive
>>>>>>>> language guidance).
>>>>>>>> Section 7.6.1:  Updated definition of
>>>>>>>> telemetryEnterpriseEndpoint.
>>>>>>>>  Section 7.6.2: Updated one line of sourcecode.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Eliot, authors - Thank you for your review and replies. You may
>>>>>>>> find the updated files at the end of this email.
>>>>>>>> 
>>>>>>>> A few follow-up questions:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> i) For question 15 below, we have updated part a as requested.
>>>>>>>> We want to confirm how to proceed with the following:
>>>>>>>> 
>>>>>>>> For part b -- should pointers to BLE 5.3 be updated to 5.4
>>>>>>>> throughout?
>>>>>>> 
>>>>>>> Go with 5.4.
>>>>>>>> 
>>>>>>>> For part c -- is the “Current” text the correct reference?
>>>>>>> 
>>>>>>> I need the text but probably the answer is “no” in relation to
>>>>>>> BLE.  However, we have only tested against 5.4, and I will not
>>>>>>> make any claims about 5.5, which introduces new encrypted
>>>>>>> advertisement capabilities.
>>>>>>> 
>>>>>>>> 
>>>>>>>>> 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].
>>>>>>>>> 
>>>>>>>>>> You’re indeed correct. That flag itself is NOT taken from
>>>>>>>>>> [BLE54].  The description should be as follows:
>>>>>>>>>> 
>>>>>>>>>> isRandom:A boolean flag. If FALSE, the device is using a
>>>>>>>>>> public MAC address. If TRUE, the device uses a random address.
>>>>>>>>>> If an Identifying Resolving Key (IRK) is present, the address
>>>>>>>>>> represents a resolvable private address. Otherwise, the
>>>>>>>>>> address is assumed to be a random static address. Non-
>>>>>>>>>> resolvable private addresses are not supported by this
>>>>>>>>>> specification. This attribute is not required. It is mutable
>>>>>>>>>> and is returned by default. The default value is FALSE.  See
>>>>>>>>>> Vol 6 Part B, Section 1.3 of [BLE54] for more information
>>>>>>>>>> about different address types.
>>>>>>>>>> 
>>>>>>>>>> We have one other issue to look at: we want to make sure we
>>>>>>>>>> are pointing to the amended 5.4 spec.  The earlier one was
>>>>>>>>>> withdrawn.  The Section # above is from the amended spec.
>>>>>>>>> 
>>>>>>>>> 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].
>>>>>>>>> -->
>>>>>>>>> 
>>>>>>>>>> Yes.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> ii) To clarify, would you like these references below to remain
>>>>>>>> as is (as two separate references)?
>>>>>>> 
>>>>>>> Actually, I think they’re one big PDF, so a reference to the same
>>>>>>> doc is fine.
>>>>>>> 
>>>>>>>> 
>>>>>>>>> 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]?
>>>>>>>>>> Yes.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> iii) We have made the update below as requested. Please provide
>>>>>>>> a reference for [OAUTHv2].
>>>>>>> 
>>>>>>> RFC 6749.
>>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>>> OLD:
>>>>>>>>> 
>>>>>>>>>> Note that either clientToken or certificateInfo is used for
>>>>>>>>>> the authentication of the application. If certificateInfo is
>>>>>>>>>> NOT present when an endpointApp object is created, then the
>>>>>>>>>> server SHOULD return a clientToken. Otherwise, if the server
>>>>>>>>>> accepts the certificateInfo object for authentication, it
>>>>>>>>>> SHOULD NOT return a clientToken. If the server accepts and
>>>>>>>>>> produces a clientToken, then control and telemetry servers
>>>>>>>>>> MUST validate both. The SCIM client will know that this is the
>>>>>>>>>> case based on the SCIM object that is returned.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Now there’s a nice big SHOULD in the middle of that, but it
>>>>>>>>> leads to a question as to when that SHOULD doesn’t apply.  The
>>>>>>>>> obvious answer is with OAUTH.  So we think the following text
>>>>>>>>> would address that point:
>>>>>>>>> 
>>>>>>>>> NEW:
>>>>>>>>> 
>>>>>>>>>> If certificateInfo is provided by the client and is accepted
>>>>>>>>>> by the server, the server MUST return that multivalued
>>>>>>>>>> attribute in its response.  Otherwise, the server is expected
>>>>>>>>>> to return a clientToken.  If the server returns neither
>>>>>>>>>> certificateInfo nor a clientToken, then external
>>>>>>>>>> authentication such as [OAUTHv2] MUST be pre-arranged.  If the
>>>>>>>>>> server accepts a certificate and produces a clientToken, then
>>>>>>>>>> control and telemetry servers MUST validate both.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> iv) We have added Sriram to the Acknowledgments. Please let us
>>>>>>>> know if there is any additional text to include.
>>>>>>>> 
>>>>>>>>> Finally, these matters were brought to our attention by Sriram
>>>>>>>>> Sekar who I would ask to be added to the acknowledgments.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> v) Note that we have updated the expansion of NIPC to Non-
>>>>>>>> Internet-Connected Physical Components (NIPC) per Rohit Mohan’s
>>>>>>>> email.
>>>>>>> 
>>>>>>> Ok
>>>>>>> 
>>>>>>>> 
>>>>>>>>> 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)
>>>>>>>>> -->
>>>>>>>> 
>>>>>>>> 
>>>>>>>> vi) Also note that we have added this Perhaps text to the
>>>>>>>> document for now. We will discuss with the team whether RESTful
>>>>>>>> should be marked as well-known (and not require expansion).
>>>>>>> 
>>>>>>> Ok
>>>>>>> 
>>>>>>> Thanks!
>>>>>>> 
>>>>>>> Eliot
>>>>>>> 
>>>>>>>> 
>>>>>>>>> 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).
>>>>>>>>> 
>>>>>>>>>> While I leave this to the RPC, might I suggest that RESTful
>>>>>>>>>> now be consider one of those industry terms of art that
>>>>>>>>>> doesn’t require expansion?
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> — 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)
>>>>>>>> 
>>>>>>>> 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 18, 2026, at 12:47 PM, Eliot Lear
>>>>>>>> <lear=[e-mail]> wrote:
>>>>>>>>> 
>>>>>>>>> Hi RFC Editor and chairs and AD:
>>>>>>>>> 
>>>>>>>>> In operational practice we have noticed two issues we would
>>>>>>>>> like to address in the RFC before it is closed.  The first has
>>>>>>>>> to do with the use of OAUTH as a means to authenticate SCIM
>>>>>>>>> connections.  Today we say in Section 6.3.1:
>>>>>>>>> 
>>>>>>>>> OLD:
>>>>>>>>> 
>>>>>>>>>> Note that either clientToken or certificateInfo is used for
>>>>>>>>>> the authentication of the application. If certificateInfo is
>>>>>>>>>> NOT present when an endpointApp object is created, then the
>>>>>>>>>> server SHOULD return a clientToken. Otherwise, if the server
>>>>>>>>>> accepts the certificateInfo object for authentication, it
>>>>>>>>>> SHOULD NOT return a clientToken. If the server accepts and
>>>>>>>>>> produces a clientToken, then control and telemetry servers
>>>>>>>>>> MUST validate both. The SCIM client will know that this is the
>>>>>>>>>> case based on the SCIM object that is returned.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Now there’s a nice big SHOULD in the middle of that, but it
>>>>>>>>> leads to a question as to when that SHOULD doesn’t apply.  The
>>>>>>>>> obvious answer is with OAUTH.  So we think the following text
>>>>>>>>> would address that point:
>>>>>>>>> 
>>>>>>>>> NEW:
>>>>>>>>> 
>>>>>>>>>> If certificateInfo is provided by the client and is accepted
>>>>>>>>>> by the server, the server MUST return that multivalued
>>>>>>>>>> attribute in its response.  Otherwise, the server is expected
>>>>>>>>>> to return a clientToken.  If the server returns neither
>>>>>>>>>> certificateInfo nor a clientToken, then external
>>>>>>>>>> authentication such as [OAUTHv2] MUST be pre-arranged.  If the
>>>>>>>>>> server accepts a certificate and produces a clientToken, then
>>>>>>>>>> control and telemetry servers MUST validate both.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> This is a bit more crisp and prescriptive.
>>>>>>>>> 
>>>>>>>>> Then in Section 7.6.1, we’ve noted one other issue:
>>>>>>>>> 
>>>>>>>>>> telemetryEnterpriseEndpoint:A string representing a URL of the
>>>>>>>>>> enterprise endpoint to reach an enterprise gateway for
>>>>>>>>>> telemetry. When the enterprise receives the SCIM object from
>>>>>>>>>> the onboarding application, it adds this attribute to it and
>>>>>>>>>> sends it back as a response to the onboarding application.
>>>>>>>>>> This attribute is optional, case sensitive, mutable, and
>>>>>>>>>> returned by default. The uniqueness is enforced by the
>>>>>>>>>> enterprise. An implementation MUST generate an exception if
>>>>>>>>>> telemetryEnterpriseEndpoint is not returned and telemetry is
>>>>>>>>>> required for the proper functioning of a device.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> It is possible that this service may be externalized.  That is,
>>>>>>>>> it’s there, but the SCIM implementation for $REASONs doesn’t
>>>>>>>>> know about it.  To address this point, we propose to replace
>>>>>>>>> the last sentence (“An implementation … a device.”) as follows:
>>>>>>>>> 
>>>>>>>>> NEW:
>>>>>>>>> 
>>>>>>>>>> This attribute is populated when the enterprise provides a
>>>>>>>>>> telemetry endpoint (e.g., hosted by the enterprise gateway).
>>>>>>>>>> If a telemetry service is not known by the SCIM server, the
>>>>>>>>>> attribute will not be returned.  In such cases, if the
>>>>>>>>>> application requires telemetry, separate arrangements must be
>>>>>>>>>> made.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Two other points:
>>>>>>>>> 
>>>>>>>>> To answer Kaelin’s earlier question, we propose to add a note
>>>>>>>>> in Section 1.3 as follows:
>>>>>>>>> 
>>>>>>>>>> When JSON is presented in this memo, it is folded in
>>>>>>>>>> accordance with RFC 8792.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Also, we caught one error in an example in Section 7.6.2.
>>>>>>>>> 
>>>>>>>>> OLD:
>>>>>>>>> 
>>>>>>>>>> "telemetryEnterpriseEndpoint": "https://example.com/\
>>>>>>>>> 
>>>>>>>>> NEW:
>>>>>>>>> 
>>>>>>>>>> "telemetryEnterpriseEndpoint": "mqtts://example.com/\
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Noting the change of URI scheme.
>>>>>>>>> 
>>>>>>>>> Finally, these matters were brought to our attention by Sriram
>>>>>>>>> Sekar who I would ask to be added to the acknowledgments.
>>>>>>>>> 
>>>>>>>>> Eliot
>>>>>>>>> 
>>>>>>>>>> On 11 Mar 2026, at 19:39, [e-mail] 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://www.rfc-
>>>>>>>>>> editor.org/faq/)
>>>>>>>>>> 
>>>>>>>>>> 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://trustee.ietf.org/license-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://authors.ietf.org/rfcxml-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
>>>>>>>>>> 
>>>>>>>>>> *  [e-mail] (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).
>>>>>>>>>> 
>>>>>>>>>> *  [e-mail], which is a new archival
>>>>>>>>>> mailing list
>>>>>>>>>> to preserve AUTH48 conversations; it is not an active
>>>>>>>>>> discussion
>>>>>>>>>> list:
>>>>>>>>>> 
>>>>>>>>>> *  More info:
>>>>>>>>>>  https://mailarchive.ietf.org/arch/msg/ietf-
>>>>>>>>>> announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>>>>>>>>>> 
>>>>>>>>>> *  The archive itself:
>>>>>>>>>>  https://mailarchive.ietf.org/arch/browse/auth48archive/
>>>>>>>>>> 
>>>>>>>>>> *  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,
>>>>>>>>>>  [e-mail] 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://www.rfc-editor.org/authors/rfc9944.xml
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9944.html
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9944.pdf
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9944.txt
>>>>>>>>>> 
>>>>>>>>>> Diff file of the text:
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9944-diff.html
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9944-rfcdiff.html (side
>>>>>>>>>> by side)
>>>>>>>>>> 
>>>>>>>>>> Diff of the XML:
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9944-xmldiff1.html
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Tracking progress
>>>>>>>>>> -----------------
>>>>>>>>>> 
>>>>>>>>>> The details of the AUTH48 status of your document are here:
>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9944
>>>>>>>>>> 
>>>>>>>>>> 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
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>