Amanda, Do you have any suggested wording we could add to help clarify things?
Eliot > On 31 Mar 2026, at 20:06, Amanda Baber via RT <[email protected]> wrote: > > 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]
