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

[Eliot Lear <[e-mail]>]

If that is okay with others, that will work for me.

Thanks all,

Eliot

> On 31 Mar 2026, at 21:14, Amanda Baber via RT <[e-mail]> wrote:
> 
> Hi Eliot,
> 
> Maybe something like this?
> 
> OLD: IANA is requested to create the following extensions in the SCIM Server-Related Schema URIs registry as described in Section 7:
> 
> NEW: IANA is requested to create the following extensions in the SCIM Server-Related Schema URIs registry (omitting the "Resource Type" field) as described in Section 7:
> 
> Amanda
> 
> On Tue Mar 31 19:05:54 2026, [e-mail] wrote:
>> 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]-
>>>>> editor.org>
>>>>> 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
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>> 
>