Hi Kaelin Please see below. With this changed, approved.
Eliot > On 27 Mar 2026, at 19:32, Kaelin Foody <[email protected]> wrote: > > Hi Eliot, all, > > Thanks for your reply -- we have updated the files accordingly and posted > them at the end of this email. Please review and let us know if these updates > are suitable. > > We will await IANA’s reply for guidance about this document's IANA > Considerations section. > > Otherwise, we believe there is only one outstanding item on our end. Please > review the following question and let us know if we may proceed with these > updates (in the “Perhaps” text below): > >> 8) <!-- [rfced] May we adjust these definitions below in order to clarify >> what >> list items "not" refers to? >> >> Original: >> >> It is not mutable, read-only, generated if no certificateInfo >> object is provisioned, case sensitive and returned by default if it exists. >> ... >> This attribute is not required, mutable, singular and NOT case >> sensitive. >> ... >> It is not required, multivalued, mutable, and returned by default. >> >> Perhaps: >> >> It is not mutable. It is read only, case sensitive, and generated if no >> certificateInfo >> object is provisioned. It is returned by default if it exists. >> ... >> This attribute is not required and not case sensitive. It is mutable and >> singular. >> ... >> It is not required. It is multivalued, mutable, and returned by default. >> >> --> Sure. >> >>> We would like to leave this text unresolved for this very moment, as we >>> have discovered a small wrinkle in the text in operation. I’ll raise that >>> in a separate email once we’ve resolved the rest of these issues. > > 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) > > All the best, > > Kaelin Foody > RFC Production Center > >> On Mar 27, 2026, at 2:16 PM, 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]
