Hi Kaelin We did note this discrepancy during an IANA expert review. My recommendation is that we not change the IANA tables at this stage, since that would require a full review of the core documents. From a functional standpoint, the fields in the registry are enough.
That having been said, if IANA wants to update these fields, I would suggest that is a process that should be reviewed at least by the designated experts, if not by the working group itself. Eliot > On 27 Mar 2026, at 19:16, 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]
