Deb, This is what Paulo noticed during the last call- the tables in the IANA registry do not perfectly match the IANA considerations in 7643.
Eliot > On 31 Mar 2026, at 13:24, Deb Cooley <[email protected]> wrote: > > There is an IANA issue? Where is the information on this? [is this a result > of the AD change, so I'm not getting messages?] > > Deb > > On Tue, Mar 31, 2026 at 5:15 AM Eliot Lear <[email protected] > <mailto:[email protected]>> wrote: >> Kaelin, >> >> On the IANA issue, my suggestion is to decouple. If IANA wants to >> restructure the registry, that’s their affair, not the RFC Editor’s. >> >> Eliot >> >> > On 27 Mar 2026, at 19:32, Kaelin Foody <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > Hi Eliot, all, >> > >> > Thanks for your reply -- we have updated the files accordingly and posted >> > them at the end of this email. Please review and let us know if these >> > updates are suitable. >> > >> > We will await IANA’s reply for guidance about this document's IANA >> > Considerations section. >> > >> > Otherwise, we believe there is only one outstanding item on our end. >> > Please review the following question and let us know if we may proceed >> > with these updates (in the “Perhaps” text below): >> > >> >> 8) <!-- [rfced] May we adjust these definitions below in order to clarify >> >> what >> >> list items "not" refers to? >> >> >> >> Original: >> >> >> >> It is not mutable, read-only, generated if no certificateInfo >> >> object is provisioned, case sensitive and returned by default if it >> >> exists. >> >> ... >> >> This attribute is not required, mutable, singular and NOT case >> >> sensitive. >> >> ... >> >> It is not required, multivalued, mutable, and returned by default. >> >> >> >> Perhaps: >> >> >> >> It is not mutable. It is read only, case sensitive, and generated if no >> >> certificateInfo >> >> object is provisioned. It is returned by default if it exists. >> >> ... >> >> This attribute is not required and not case sensitive. It is mutable and >> >> singular. >> >> ... >> >> It is not required. It is multivalued, mutable, and returned by default. >> >> >> >> --> >> >> >> >>> We would like to leave this text unresolved for this very moment, as we >> >>> have discovered a small wrinkle in the text in operation. I’ll raise >> >>> that in a separate email once we’ve resolved the rest of these issues. >> > >> > 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) >> > >> > All the best, >> > >> > Kaelin Foody >> > RFC Production Center >> > >> >> On Mar 27, 2026, at 2:16 PM, Kaelin Foody <[email protected] >> >> <mailto:[email protected]>> 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] >> >>> <mailto:[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] >> >>>> <mailto:[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] >> >>>>> <mailto:[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] >> >>>>> <mailto:[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] >> >>>>> <mailto:[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] >> >>>>>> <mailto:[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] >> >>>>>> <mailto:[email protected]>> wrote: >> >>>>>> >> >>>>>> >> >>>>>>> On 20 Mar 2026, at 15:32, Kaelin Foody <[email protected] >> >>>>>>> <mailto:[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] >> >>>>>>> <mailto:[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/\ >> >>>>>>>>> <https://example.com/%5C> >> >>>>>>>> >> >>>>>>>> NEW: >> >>>>>>>> >> >>>>>>>>> "telemetryEnterpriseEndpoint": "mqtts://example.com/\ >> >>>>>>>>> <http://example.com/%5C> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> 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] >> >>>>>>>>> <mailto:[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] <mailto:[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] >> >>>>>>>>> <mailto:[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] >> >>>>>>>>> <mailto:[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]
