From the IANA expert perspective it IS okay. But the registry itself is inconsistent with 7643. That’s not a comment on the device doc- just the registry.
Eliot > On 31 Mar 2026, at 14:03, Deb Cooley <[email protected]> wrote: > > I thought that had been resolved? The datatracker says 'Expert Review OK'. > [My memory has seen better days, both age and digging out from IETF 125 and > the fog of actions. I'm happy to be corrected.] > > I'm not going to pull up mailarchive links.... but 25 June 2025, Amanda > issued their ballot: IANA OK.... (this only went to the IESG) > > Deb > > On Tue, Mar 31, 2026 at 7:41 AM Eliot Lear <[email protected] > <mailto:[email protected]>> wrote: >> 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] >>> <mailto:[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]
