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