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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >> Hi All, >> >> The address currently listed for me and Hassan is good. >> >> On Tue, Mar 24, 2026 at 11:44 AM Eliot Lear <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>> >>> >>>> On 20 Mar 2026, at 15:32, Kaelin Foody <[email protected]> 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 <[email protected]> >>>> 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, [email protected] 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 >>>>>> >>>>>> * [email protected] (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). >>>>>> >>>>>> * [email protected], 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, >>>>>> [email protected] 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 >>>>>> >>>>>> >>>>> >>>> >>> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
