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 <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/\ > <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] 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]
