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