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

[Eliot Lear <[e-mail]>]

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]> 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]> 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
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>