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, [email protected] 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 <[email protected]> > > 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, [email protected] 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 <[email protected] > >>> 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 <[email protected]> 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 <[email protected] > >>>>> 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 <[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] > >>>>>>>> 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 > >>>>>>>> <[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]
