Hi Eliot, all, We have added this sentence to Section 9.2 per IANA’s suggestion:
OLD: IANA has created the following extensions in the "SCIM Server-Related Schema URIs" registry as described in Section 7: NEW: IANA has created the following extensions in the "SCIM Server-Related Schema URIs" registry (omitting the "Resource Type" field) as described in Section 7: Otherwise, 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) All the best, Kaelin Foody RFC Production Center > On Mar 31, 2026, at 2:57 PM, Kaelin Foody <[email protected]> wrote: > > Hi Eliot, Deb, all, > > Eliot - Regarding your note below: > >> 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. > > It seems the preference is for the IANA registry to NOT be updated. In that > case, should the lines that list “Resource Type: Device” in Section 9.2 of > this document be cut in order to match the current registry structure? Or > should this information remain as is? > > > Deb - Below is a copy of the original email to IANA for your convenience: > >> 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”). > > 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 31, 2026, at 11:17 AM, Eliot Lear <[email protected]> wrote: >> >> 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]> 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]> 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]> 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]> >>>>> 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]> >>>>>> 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]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Deb, Eliot, all, >>>>>>>> >>>>>>>> Deb - Thank you for your approval. We have marked it here: >>>>>>>> https://www.rfc-editor.org/auth48/rfc9944. >>>>>>>> >>>>>>>> Eliot - Thank you for your reply. We have updated the document >>>>>>>> according to your responses. You may find the updated files at the end >>>>>>>> of this email. >>>>>>>> >>>>>>>> One additional note: >>>>>>>> >>>>>>>>> Should pointers to BLE 5.3 be updated to 5.4 throughout? >>>>>>>>> >>>>>>>>>> Go with 5.4. >>>>>>>> >>>>>>>> For above, we have updated instances of BLE 5.3 to 5.4 throughout, but >>>>>>>> some of these changes were made in the sourcecode. Please carefully >>>>>>>> review these changes to ensure they are accurate (see: >>>>>>>> https://www.rfc-editor.org/authors/rfc9944-lastrfcdiff.html) and let >>>>>>>> us know if any additional changes need to be made. >>>>>>>> >>>>>>>> Please also note that we will ask IANA to update their registries to >>>>>>>> match the edited document shortly. >>>>>>>> >>>>>>>> Upon careful review, please contact us with any further updates or >>>>>>>> with your approval of the document in its current form. We will await >>>>>>>> approvals from each party listed on the AUTH48 status page for this >>>>>>>> document prior to moving forward in the publication process. >>>>>>>> >>>>>>>> The AUTH48 status page for this document is available here: >>>>>>>> https://www.rfc-editor.org/auth48/rfc9944 >>>>>>>> >>>>>>>> — FILES (please refresh): — >>>>>>>> >>>>>>>> The updated files have been posted here: >>>>>>>> https://www.rfc-editor.org/authors/rfc9944.txt >>>>>>>> https://www.rfc-editor.org/authors/rfc9944.pdf >>>>>>>> https://www.rfc-editor.org/authors/rfc9944.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9944.xml >>>>>>>> >>>>>>>> Diff files showing changes between the last and current version: >>>>>>>> https://www.rfc-editor.org/authors/rfc9944-lastdiff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9944-lastrfcdiff.html (side by >>>>>>>> side) >>>>>>>> >>>>>>>> Diff files showing changes made during AUTH48: >>>>>>>> https://www.rfc-editor.org/authors/rfc9944-auth48diff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9944-auth48rfcdiff.html (side by >>>>>>>> side) >>>>>>>> >>>>>>>> Diff files showing all changes: >>>>>>>> https://www.rfc-editor.org/authors/rfc9944-diff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9944-rfcdiff.html (side by side) >>>>>>>> >>>>>>>> Thank you, >>>>>>>> >>>>>>>> Kaelin Foody >>>>>>>> RFC Production Center >>>>>>>> >>>>>>>>> On Mar 24, 2026, at 2:39 PM, Deb Cooley <[email protected]> wrote: >>>>>>>>> >>>>>>>>> Thanks for that. I'm glad they are employer phone numbers. No one >>>>>>>>> needs more spam on their personal phones. >>>>>>>>> >>>>>>>>> Deb >>>>>>>>> >>>>>>>>> On Tue, Mar 24, 2026 at 12:28 PM Muhammad Shahzad <[email protected]> >>>>>>>>> wrote: >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> The address currently listed for me and Hassan is good. >>>>>>>>> >>>>>>>>> On Tue, Mar 24, 2026 at 11:44 AM Eliot Lear <[email protected]> wrote: >>>>>>>>> It’s a Cisco main #, and our address. I’m okay with it. Muhammed? >>>>>>>>> Hassan? >>>>>>>>> >>>>>>>>> Eliot >>>>>>>>> >>>>>>>>>> On 24 Mar 2026, at 12:23, Deb Cooley <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> Apologies, I missed the *AD note.....(both from Kaelin and Eliot). >>>>>>>>>> >>>>>>>>>> I've checked the diff and subsequent message from Eliot pretty >>>>>>>>>> carefully (especially the SHOULD/MUST change) and it all appears to >>>>>>>>>> be fine. I approve the changes. >>>>>>>>>> >>>>>>>>>> I only have one comment wrt Author Addresses: These are super >>>>>>>>>> specific. In the case of the NC State authors, it appears that the >>>>>>>>>> address is a department address, clearly already public. For Eliot, >>>>>>>>>> that is your personal address, no? And the phone number? I haven't >>>>>>>>>> seen too many phone numbers on drafts/RFCs. This is your call, but >>>>>>>>>> I think it would be reasonable (and mostly the norm) to remove the >>>>>>>>>> actual street address and phone number. >>>>>>>>>> >>>>>>>>>> Deb >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Mar 24, 2026 at 5:52 AM Eliot Lear <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 20 Mar 2026, at 15:32, Kaelin Foody >>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi *Deb, Eliot, all, >>>>>>>>>>> >>>>>>>>>>> *Deb - As AD, please review the following changes to this document. >>>>>>>>>>> >>>>>>>>>>> You may view them in the diff here: >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9944-lastdiff.html. >>>>>>>>>>> >>>>>>>>>>> There is additional context in this email thread regarding these >>>>>>>>>>> changes, but we have summarized them below: >>>>>>>>>>> >>>>>>>>>>> Section 1.3: Added sentence re: line wrapping per RFC 8792. >>>>>>>>>>> Section 6.3.1: Updated paragraph that appears after Table 2. >>>>>>>>>>> Section 7.6: Removed sentence in first paragraph (per inclusive >>>>>>>>>>> language guidance). >>>>>>>>>>> Section 7.6.1: Updated definition of telemetryEnterpriseEndpoint. >>>>>>>>>>> Section 7.6.2: Updated one line of sourcecode. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Eliot, authors - Thank you for your review and replies. You may >>>>>>>>>>> find the updated files at the end of this email. >>>>>>>>>>> >>>>>>>>>>> A few follow-up questions: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> i) For question 15 below, we have updated part a as requested. We >>>>>>>>>>> want to confirm how to proceed with the following: >>>>>>>>>>> >>>>>>>>>>> For part b -- should pointers to BLE 5.3 be updated to 5.4 >>>>>>>>>>> throughout? >>>>>>>>>> >>>>>>>>>> Go with 5.4. >>>>>>>>>>> >>>>>>>>>>> For part c -- is the “Current” text the correct reference? >>>>>>>>>> >>>>>>>>>> I need the text but probably the answer is “no” in relation to BLE. >>>>>>>>>> However, we have only tested against 5.4, and I will not make any >>>>>>>>>> claims about 5.5, which introduces new encrypted advertisement >>>>>>>>>> capabilities. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> 15) <!-- [rfced] [BLE54]: Please review the following questions >>>>>>>>>>>> regarding this reference: >>>>>>>>>>>> >>>>>>>>>>>> a) We were unable to find "isRandom" mentioned in [BLE54] as seen >>>>>>>>>>>> below. Should this citation be updated? >>>>>>>>>>>> >>>>>>>>>>>> Original: >>>>>>>>>>>> >>>>>>>>>>>> isRandom: A boolean flag taken from [BLE54]. >>>>>>>>>>>> >>>>>>>>>>>>> You’re indeed correct. That flag itself is NOT taken from >>>>>>>>>>>>> [BLE54]. The description should be as follows: >>>>>>>>>>>>> >>>>>>>>>>>>> isRandom:A boolean flag. If FALSE, the device is using a public >>>>>>>>>>>>> MAC address. If TRUE, the device uses a random address. If an >>>>>>>>>>>>> Identifying Resolving Key (IRK) is present, the address >>>>>>>>>>>>> represents a resolvable private address. Otherwise, the address >>>>>>>>>>>>> is assumed to be a random static address. Non-resolvable private >>>>>>>>>>>>> addresses are not supported by this specification. This attribute >>>>>>>>>>>>> is not required. It is mutable and is returned by default. The >>>>>>>>>>>>> default value is FALSE. See Vol 6 Part B, Section 1.3 of [BLE54] >>>>>>>>>>>>> for more information about different address types. >>>>>>>>>>>>> >>>>>>>>>>>>> We have one other issue to look at: we want to make sure we are >>>>>>>>>>>>> pointing to the amended 5.4 spec. The earlier one was withdrawn. >>>>>>>>>>>>> The Section # above is from the amended spec. >>>>>>>>>>>> >>>>>>>>>>>> b) We also note a few instances of "BLE core specifications 5.3" >>>>>>>>>>>> mentioned >>>>>>>>>>>> throughout this document. However, the Normative References >>>>>>>>>>>> section cites >>>>>>>>>>>> Version 5.4. Please review and let us know if/how to update >>>>>>>>>>>> accordingly. >>>>>>>>>>>> >>>>>>>>>>>> For example: >>>>>>>>>>>> >>>>>>>>>>>> "description": "The isRandom flag is taken from the BLE >>>>>>>>>>>> core specifications 5.3. If TRUE, device is using a >>>>>>>>>>>> random address. Default value is false.", >>>>>>>>>>>> >>>>>>>>>>>> c) Please review our updates to the text below. There are multiple >>>>>>>>>>>> volumes in >>>>>>>>>>>> [BLE54]; it appears Section 5.4.5 is referring to Volume 1, Part >>>>>>>>>>>> A, Section >>>>>>>>>>>> 5.4.5 of [BLE54]. Is this the correct section? >>>>>>>>>>>> >>>>>>>>>>>> Original: >>>>>>>>>>>> >>>>>>>>>>>> For more information about the use of the IRK, see Section 5.4.5 of >>>>>>>>>>>> [BLE54]. >>>>>>>>>>>> >>>>>>>>>>>> Current: >>>>>>>>>>>> >>>>>>>>>>>> For more information about the use of the IRK, see Volume 1, Part >>>>>>>>>>>> A, >>>>>>>>>>>> Section 5.4.5 of [BLE54]. >>>>>>>>>>>> --> >>>>>>>>>>>> >>>>>>>>>>>>> Yes. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ii) To clarify, would you like these references below to remain as >>>>>>>>>>> is (as two separate references)? >>>>>>>>>> >>>>>>>>>> Actually, I think they’re one big PDF, so a reference to the same >>>>>>>>>> doc is fine. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> 16) <!-- [rfced] References: >>>>>>>>>>>> >>>>>>>>>>>> a) We note that [draft-brinckman-nipc] was replaced by >>>>>>>>>>>> [draft-ietf-asdf-nipc]. >>>>>>>>>>>> Should these remain as two separate references? Or, would you like >>>>>>>>>>>> to remove >>>>>>>>>>>> the citation to [draft-brinckman-nipc] and only keep the >>>>>>>>>>>> reference to [draft-ietf-asdf-nipc]? >>>>>>>>>>>>> Yes. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> iii) We have made the update below as requested. Please provide a >>>>>>>>>>> reference for [OAUTHv2]. >>>>>>>>>> >>>>>>>>>> RFC 6749. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> OLD: >>>>>>>>>>>> >>>>>>>>>>>>> Note that either clientToken or certificateInfo is used for the >>>>>>>>>>>>> authentication of the application. If certificateInfo is NOT >>>>>>>>>>>>> present when an endpointApp object is created, then the server >>>>>>>>>>>>> SHOULD return a clientToken. Otherwise, if the server accepts the >>>>>>>>>>>>> certificateInfo object for authentication, it SHOULD NOT return a >>>>>>>>>>>>> clientToken. If the server accepts and produces a clientToken, >>>>>>>>>>>>> then control and telemetry servers MUST validate both. The SCIM >>>>>>>>>>>>> client will know that this is the case based on the SCIM object >>>>>>>>>>>>> that is returned. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Now there’s a nice big SHOULD in the middle of that, but it leads >>>>>>>>>>>> to a question as to when that SHOULD doesn’t apply. The obvious >>>>>>>>>>>> answer is with OAUTH. So we think the following text would >>>>>>>>>>>> address that point: >>>>>>>>>>>> >>>>>>>>>>>> NEW: >>>>>>>>>>>> >>>>>>>>>>>>> If certificateInfo is provided by the client and is accepted by >>>>>>>>>>>>> the server, the server MUST return that multivalued attribute in >>>>>>>>>>>>> its response. Otherwise, the server is expected to return a >>>>>>>>>>>>> clientToken. If the server returns neither certificateInfo nor a >>>>>>>>>>>>> clientToken, then external authentication such as [OAUTHv2] MUST >>>>>>>>>>>>> be pre-arranged. If the server accepts a certificate and >>>>>>>>>>>>> produces a clientToken, then control and telemetry servers MUST >>>>>>>>>>>>> validate both. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> iv) We have added Sriram to the Acknowledgments. Please let us know >>>>>>>>>>> if there is any additional text to include. >>>>>>>>>>> >>>>>>>>>>>> Finally, these matters were brought to our attention by Sriram >>>>>>>>>>>> Sekar who I would ask to be added to the acknowledgments. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> v) Note that we have updated the expansion of NIPC to >>>>>>>>>>> Non-Internet-Connected Physical Components (NIPC) per Rohit Mohan’s >>>>>>>>>>> email. >>>>>>>>>> >>>>>>>>>> Ok >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> c) FYI - We have added expansions for the following abbreviations. >>>>>>>>>>>> Please review >>>>>>>>>>>> each expansion in the document carefully to ensure correctness. >>>>>>>>>>>> >>>>>>>>>>>> Certificate Authority (CA) >>>>>>>>>>>> Near Field Communication (NFC) >>>>>>>>>>>> Non-IP Device Control (NIPC) >>>>>>>>>>>> Universally Unique Identifier (UUID) >>>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> vi) Also note that we have added this Perhaps text to the document >>>>>>>>>>> for now. We will discuss with the team whether RESTful should be >>>>>>>>>>> marked as well-known (and not require expansion). >>>>>>>>>> >>>>>>>>>> Ok >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>> Eliot >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> b) May we expand "RESTful" by providing a definition as follows? >>>>>>>>>>>> >>>>>>>>>>>> Original: >>>>>>>>>>>> >>>>>>>>>>>> confirmationNumber: An integer which some solutions require in >>>>>>>>>>>> RESTful message exchange. >>>>>>>>>>>> >>>>>>>>>>>> Perhaps: >>>>>>>>>>>> >>>>>>>>>>>> confirmationNumber: An integer that some solutions require in >>>>>>>>>>>> a RESTful message exchange (where RESTful refers to the >>>>>>>>>>>> Representational >>>>>>>>>>>> State Transfer (REST) architecture). >>>>>>>>>>>> >>>>>>>>>>>>> While I leave this to the RPC, might I suggest that RESTful now >>>>>>>>>>>>> be consider one of those industry terms of art that doesn’t >>>>>>>>>>>>> require expansion? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> — FILES (please refresh): — >>>>>>>>>>> >>>>>>>>>>> The updated files have been posted here: >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9944.txt >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9944.pdf >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9944.html >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9944.xml >>>>>>>>>>> >>>>>>>>>>> Diff files showing changes between the last and current version: >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9944-lastdiff.html >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9944-lastrfcdiff.html (side >>>>>>>>>>> by side) >>>>>>>>>>> >>>>>>>>>>> Diff files showing changes made during AUTH48: >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9944-auth48diff.html >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9944-auth48rfcdiff.html (side >>>>>>>>>>> by side) >>>>>>>>>>> >>>>>>>>>>> Diff files showing all changes: >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9944-diff.html >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9944-rfcdiff.html (side by >>>>>>>>>>> side) >>>>>>>>>>> >>>>>>>>>>> The AUTH48 status page for this document is available here: >>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9944 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thank you, >>>>>>>>>>> >>>>>>>>>>> Kaelin Foody >>>>>>>>>>> RFC Production Center >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mar 18, 2026, at 12:47 PM, Eliot Lear >>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi RFC Editor and chairs and AD: >>>>>>>>>>>> >>>>>>>>>>>> In operational practice we have noticed two issues we would like >>>>>>>>>>>> to address in the RFC before it is closed. The first has to do >>>>>>>>>>>> with the use of OAUTH as a means to authenticate SCIM connections. >>>>>>>>>>>> Today we say in Section 6.3.1: >>>>>>>>>>>> >>>>>>>>>>>> OLD: >>>>>>>>>>>> >>>>>>>>>>>>> Note that either clientToken or certificateInfo is used for the >>>>>>>>>>>>> authentication of the application. If certificateInfo is NOT >>>>>>>>>>>>> present when an endpointApp object is created, then the server >>>>>>>>>>>>> SHOULD return a clientToken. Otherwise, if the server accepts the >>>>>>>>>>>>> certificateInfo object for authentication, it SHOULD NOT return a >>>>>>>>>>>>> clientToken. If the server accepts and produces a clientToken, >>>>>>>>>>>>> then control and telemetry servers MUST validate both. The SCIM >>>>>>>>>>>>> client will know that this is the case based on the SCIM object >>>>>>>>>>>>> that is returned. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Now there’s a nice big SHOULD in the middle of that, but it leads >>>>>>>>>>>> to a question as to when that SHOULD doesn’t apply. The obvious >>>>>>>>>>>> answer is with OAUTH. So we think the following text would >>>>>>>>>>>> address that point: >>>>>>>>>>>> >>>>>>>>>>>> NEW: >>>>>>>>>>>> >>>>>>>>>>>>> If certificateInfo is provided by the client and is accepted by >>>>>>>>>>>>> the server, the server MUST return that multivalued attribute in >>>>>>>>>>>>> its response. Otherwise, the server is expected to return a >>>>>>>>>>>>> clientToken. If the server returns neither certificateInfo nor a >>>>>>>>>>>>> clientToken, then external authentication such as [OAUTHv2] MUST >>>>>>>>>>>>> be pre-arranged. If the server accepts a certificate and >>>>>>>>>>>>> produces a clientToken, then control and telemetry servers MUST >>>>>>>>>>>>> validate both. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This is a bit more crisp and prescriptive. >>>>>>>>>>>> >>>>>>>>>>>> Then in Section 7.6.1, we’ve noted one other issue: >>>>>>>>>>>> >>>>>>>>>>>>> telemetryEnterpriseEndpoint:A string representing a URL of the >>>>>>>>>>>>> enterprise endpoint to reach an enterprise gateway for telemetry. >>>>>>>>>>>>> When the enterprise receives the SCIM object from the onboarding >>>>>>>>>>>>> application, it adds this attribute to it and sends it back as a >>>>>>>>>>>>> response to the onboarding application. This attribute is >>>>>>>>>>>>> optional, case sensitive, mutable, and returned by default. The >>>>>>>>>>>>> uniqueness is enforced by the enterprise. An implementation MUST >>>>>>>>>>>>> generate an exception if telemetryEnterpriseEndpoint is not >>>>>>>>>>>>> returned and telemetry is required for the proper functioning of >>>>>>>>>>>>> a device. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> It is possible that this service may be externalized. That is, >>>>>>>>>>>> it’s there, but the SCIM implementation for $REASONs doesn’t know >>>>>>>>>>>> about it. To address this point, we propose to replace the last >>>>>>>>>>>> sentence (“An implementation … a device.”) as follows: >>>>>>>>>>>> >>>>>>>>>>>> NEW: >>>>>>>>>>>> >>>>>>>>>>>>> This attribute is populated when the enterprise provides a >>>>>>>>>>>>> telemetry endpoint (e.g., hosted by the enterprise gateway). If >>>>>>>>>>>>> a telemetry service is not known by the SCIM server, the >>>>>>>>>>>>> attribute will not be returned. In such cases, if the >>>>>>>>>>>>> application requires telemetry, separate arrangements must be >>>>>>>>>>>>> made. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Two other points: >>>>>>>>>>>> >>>>>>>>>>>> To answer Kaelin’s earlier question, we propose to add a note in >>>>>>>>>>>> Section 1.3 as follows: >>>>>>>>>>>> >>>>>>>>>>>>> When JSON is presented in this memo, it is folded in accordance >>>>>>>>>>>>> with RFC 8792. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Also, we caught one error in an example in Section 7.6.2. >>>>>>>>>>>> >>>>>>>>>>>> OLD: >>>>>>>>>>>> >>>>>>>>>>>>> "telemetryEnterpriseEndpoint": "https://example.com/\ >>>>>>>>>>>> >>>>>>>>>>>> NEW: >>>>>>>>>>>> >>>>>>>>>>>>> "telemetryEnterpriseEndpoint": "mqtts://example.com/\ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Noting the change of URI scheme. >>>>>>>>>>>> >>>>>>>>>>>> Finally, these matters were brought to our attention by Sriram >>>>>>>>>>>> Sekar who I would ask to be added to the acknowledgments. >>>>>>>>>>>> >>>>>>>>>>>> Eliot >>>>>>>>>>>> >>>>>>>>>>>>> On 11 Mar 2026, at 19:39, [email protected] wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> *****IMPORTANT***** >>>>>>>>>>>>> >>>>>>>>>>>>> Updated 2026/03/11 >>>>>>>>>>>>> >>>>>>>>>>>>> RFC Author(s): >>>>>>>>>>>>> -------------- >>>>>>>>>>>>> >>>>>>>>>>>>> Instructions for Completing AUTH48 >>>>>>>>>>>>> >>>>>>>>>>>>> Your document has now entered AUTH48. Once it has been reviewed >>>>>>>>>>>>> and >>>>>>>>>>>>> approved by you and all coauthors, it will be published as an >>>>>>>>>>>>> RFC. >>>>>>>>>>>>> If an author is no longer available, there are several remedies >>>>>>>>>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >>>>>>>>>>>>> >>>>>>>>>>>>> You and you coauthors are responsible for engaging other parties >>>>>>>>>>>>> (e.g., Contributors or Working Group) as necessary before >>>>>>>>>>>>> providing >>>>>>>>>>>>> your approval. >>>>>>>>>>>>> >>>>>>>>>>>>> Planning your review >>>>>>>>>>>>> --------------------- >>>>>>>>>>>>> >>>>>>>>>>>>> Please review the following aspects of your document: >>>>>>>>>>>>> >>>>>>>>>>>>> * RFC Editor questions >>>>>>>>>>>>> >>>>>>>>>>>>> Please review and resolve any questions raised by the RFC Editor >>>>>>>>>>>>> that have been included in the XML file as comments marked as >>>>>>>>>>>>> follows: >>>>>>>>>>>>> >>>>>>>>>>>>> <!-- [rfced] ... --> >>>>>>>>>>>>> >>>>>>>>>>>>> These questions will also be sent in a subsequent email. >>>>>>>>>>>>> >>>>>>>>>>>>> * Changes submitted by coauthors >>>>>>>>>>>>> >>>>>>>>>>>>> Please ensure that you review any changes submitted by your >>>>>>>>>>>>> coauthors. We assume that if you do not speak up that you >>>>>>>>>>>>> agree to changes submitted by your coauthors. >>>>>>>>>>>>> >>>>>>>>>>>>> * Content >>>>>>>>>>>>> >>>>>>>>>>>>> Please review the full content of the document, as this cannot >>>>>>>>>>>>> change once the RFC is published. Please pay particular >>>>>>>>>>>>> attention to: >>>>>>>>>>>>> - IANA considerations updates (if applicable) >>>>>>>>>>>>> - contact information >>>>>>>>>>>>> - references >>>>>>>>>>>>> >>>>>>>>>>>>> * Copyright notices and legends >>>>>>>>>>>>> >>>>>>>>>>>>> Please review the copyright notice and legends as defined in >>>>>>>>>>>>> RFC 5378 and the Trust Legal Provisions >>>>>>>>>>>>> (TLP – https://trustee.ietf.org/license-info). >>>>>>>>>>>>> >>>>>>>>>>>>> * Semantic markup >>>>>>>>>>>>> >>>>>>>>>>>>> Please review the markup in the XML file to ensure that elements >>>>>>>>>>>>> of >>>>>>>>>>>>> content are correctly tagged. For example, ensure that >>>>>>>>>>>>> <sourcecode> >>>>>>>>>>>>> and <artwork> are set correctly. See details at >>>>>>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>. >>>>>>>>>>>>> >>>>>>>>>>>>> * Formatted output >>>>>>>>>>>>> >>>>>>>>>>>>> Please review the PDF, HTML, and TXT files to ensure that the >>>>>>>>>>>>> formatted output, as generated from the markup in the XML file, >>>>>>>>>>>>> is >>>>>>>>>>>>> reasonable. Please note that the TXT will have formatting >>>>>>>>>>>>> limitations compared to the PDF and HTML. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Submitting changes >>>>>>>>>>>>> ------------------ >>>>>>>>>>>>> >>>>>>>>>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ >>>>>>>>>>>>> as all >>>>>>>>>>>>> the parties CCed on this message need to see your changes. The >>>>>>>>>>>>> parties >>>>>>>>>>>>> include: >>>>>>>>>>>>> >>>>>>>>>>>>> * your coauthors >>>>>>>>>>>>> >>>>>>>>>>>>> * [email protected] (the RPC team) >>>>>>>>>>>>> >>>>>>>>>>>>> * other document participants, depending on the stream (e.g., >>>>>>>>>>>>> IETF Stream participants are your working group chairs, the >>>>>>>>>>>>> responsible ADs, and the document shepherd). >>>>>>>>>>>>> >>>>>>>>>>>>> * [email protected], which is a new archival mailing >>>>>>>>>>>>> list >>>>>>>>>>>>> to preserve AUTH48 conversations; it is not an active discussion >>>>>>>>>>>>> list: >>>>>>>>>>>>> >>>>>>>>>>>>> * More info: >>>>>>>>>>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >>>>>>>>>>>>> >>>>>>>>>>>>> * The archive itself: >>>>>>>>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>>>>>>>>>>> >>>>>>>>>>>>> * Note: If only absolutely necessary, you may temporarily opt >>>>>>>>>>>>> out >>>>>>>>>>>>> of the archiving of messages (e.g., to discuss a sensitive >>>>>>>>>>>>> matter). >>>>>>>>>>>>> If needed, please add a note at the top of the message that you >>>>>>>>>>>>> have dropped the address. When the discussion is concluded, >>>>>>>>>>>>> [email protected] will be re-added to the CC list and >>>>>>>>>>>>> its addition will be noted at the top of the message. >>>>>>>>>>>>> >>>>>>>>>>>>> You may submit your changes in one of two ways: >>>>>>>>>>>>> >>>>>>>>>>>>> An update to the provided XML file >>>>>>>>>>>>> — OR — >>>>>>>>>>>>> An explicit list of changes in this format >>>>>>>>>>>>> >>>>>>>>>>>>> Section # (or indicate Global) >>>>>>>>>>>>> >>>>>>>>>>>>> OLD: >>>>>>>>>>>>> old text >>>>>>>>>>>>> >>>>>>>>>>>>> NEW: >>>>>>>>>>>>> new text >>>>>>>>>>>>> >>>>>>>>>>>>> You do not need to reply with both an updated XML file and an >>>>>>>>>>>>> explicit >>>>>>>>>>>>> list of changes, as either form is sufficient. >>>>>>>>>>>>> >>>>>>>>>>>>> We will ask a stream manager to review and approve any changes >>>>>>>>>>>>> that seem >>>>>>>>>>>>> beyond editorial in nature, e.g., addition of new text, deletion >>>>>>>>>>>>> of text, >>>>>>>>>>>>> and technical changes. Information about stream managers can be >>>>>>>>>>>>> found in >>>>>>>>>>>>> the FAQ. Editorial changes do not require approval from a stream >>>>>>>>>>>>> manager. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Approving for publication >>>>>>>>>>>>> -------------------------- >>>>>>>>>>>>> >>>>>>>>>>>>> To approve your RFC for publication, please reply to this email >>>>>>>>>>>>> stating >>>>>>>>>>>>> that you approve this RFC for publication. Please use ‘REPLY >>>>>>>>>>>>> ALL’, >>>>>>>>>>>>> as all the parties CCed on this message need to see your approval. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Files >>>>>>>>>>>>> ----- >>>>>>>>>>>>> >>>>>>>>>>>>> The files are available here: >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9944.xml >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9944.html >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9944.pdf >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9944.txt >>>>>>>>>>>>> >>>>>>>>>>>>> Diff file of the text: >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9944-diff.html >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9944-rfcdiff.html (side by >>>>>>>>>>>>> side) >>>>>>>>>>>>> >>>>>>>>>>>>> Diff of the XML: >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9944-xmldiff1.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Tracking progress >>>>>>>>>>>>> ----------------- >>>>>>>>>>>>> >>>>>>>>>>>>> The details of the AUTH48 status of your document are here: >>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9944 >>>>>>>>>>>>> >>>>>>>>>>>>> Please let us know if you have any questions. >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you for your cooperation, >>>>>>>>>>>>> >>>>>>>>>>>>> RFC Editor >>>>>>>>>>>>> >>>>>>>>>>>>> -------------------------------------- >>>>>>>>>>>>> RFC9944 (draft-ietf-scim-device-model-18) >>>>>>>>>>>>> >>>>>>>>>>>>> Title : Device Schema Extensions to the SCIM model >>>>>>>>>>>>> Author(s) : M. Shahzad, H. Iqbal, E. Lear >>>>>>>>>>>>> WG Chair(s) : Nancy Cam-Winget >>>>>>>>>>>>> Area Director(s) : Deb Cooley, Paul Wouters >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
