Hi, To create a new field, IANA would need instructions from an RFC or, if they see a clear need for it (per RFC 8126, Section 2.4), the ADs. If that's not appropriate, would it make sense to add a line that mentions that the registry doesn't include a "Resource Type" field, and that this field is being included in Table 10 for the readers' information, or something along those lines? I think our concern is just that someone might read the IANA Considerations section and wonder if the registry could have been misidentified.
thanks, Amanda On Fri Mar 27 18:47:42 2026, [email protected] wrote: > 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] > >>> editor.org> 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] > >>>>>> editor.org> 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]
