Thanks, Kaelin. @Hassan, @Muhammed. Your turn. Eliot
> On 1 Apr 2026, at 15:59, Kaelin Foody <[email protected]> wrote: > > 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]
