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