Sure. I'll keep you posted. Best Fabien On Mon, 14 Apr 2025, 23:59 Justin Richer, <jric...@mit.edu> wrote:
> OK, I think the best bet is to keep the acert.io address on the > specification but make sure your gmail account is CC’d on the discussion, > what do you think? > > I’m reviewing the final diffs now, Fabien please do the same when you get > a chance and approve or offer changes as needed. > > Thanks all, > > — Justin > > On Apr 14, 2025, at 5:52 PM, Fabien Imbault <fabien.imba...@gmail.com> > wrote: > > Well actually there is an issue with the payment for some obscure reason. > My sincere apologies, the easiest will be to change for a free account > that I'm sure will never have that sort of issue. > > Please let me know if there's anything I can do to help further. > > Best > Fabien > > On Mon, 14 Apr 2025, 23:45 Fabien Imbault, <fabien.imba...@gmail.com> > wrote: > >> Hi there, I have no idea, my email account is perfectly fine and I do >> receive ietf notifications. Yet if that's really an issue you may use >> fabien.imba...@gmail.com if needed. >> >> Best regards >> Fabien >> >> On Mon, 14 Apr 2025, 21:06 Justin Richer, <jric...@mit.edu> wrote: >> >>> Hi Karen, >>> >>> This happened recently with RFC9635 (GNAP Core), so I’m CC’ing his other >>> known address as I know he’ll need to approve as well. >>> >>> Fabien, any idea what’s going on here, and should we update the contact >>> info on the draft? >>> >>> — Justin >>> >>> > On Apr 14, 2025, at 2:34 PM, Karen Moore <kmo...@staff.rfc-editor.org> >>> wrote: >>> > >>> > Hi Justin, >>> > >>> > We received a bounced message for fabien.imba...@acert.io. Do you >>> happen to know if Fabien has a new email address? >>> > >>> > Thank you. >>> > RFC Editor/kc >>> > >>> >> On Apr 14, 2025, at 10:55 AM, Karen Moore < >>> kmo...@staff.rfc-editor.org> wrote: >>> >> >>> >> Hi Justin, >>> >> >>> >> Thank you for your reply. We have updated our files accordingly. >>> Please review and let us know if any further changes are needed or if you >>> approve the document in its current form. We will await approvals from each >>> author prior to moving forward in the publication process. >>> >> >>> >> --FILES-- >>> >> >>> >> The updated XML file is here: >>> >> https://www.rfc-editor.org/authors/rfc9767.xml >>> >> >>> >> The updated output files are here: >>> >> https://www.rfc-editor.org/authors/rfc9767.txt >>> >> https://www.rfc-editor.org/authors/rfc9767.pdf >>> >> https://www.rfc-editor.org/authors/rfc9767.html >>> >> >>> >> These diff files show all changes made during AUTH48: >>> >> https://www.rfc-editor.org/authors/rfc9767-auth48diff.html >>> >> https://www.rfc-editor.org/authors/rfc9767-auth48rfcdiff.html (side >>> by side) >>> >> >>> >> These diff files show all changes made to date: >>> >> https://www.rfc-editor.org/authors/rfcXXXX-diff.html >>> >> https://www.rfc-editor.org/authors/rfc9767-rfcdiff.html (side by >>> side) >>> >> >>> >> Note that it may be necessary for you to refresh your browser to view >>> the most recent version. Please review the document carefully to ensure >>> satisfaction as we do not make changes once it has been published as an RFC. >>> >> >>> >> For the AUTH48 status of this document, please see: >>> >> https://www.rfc-editor.org/auth48/rfc9767 >>> >> >>> >> Thank you, >>> >> RFC Editor/kc >>> >> >>> >> >>> >>> On Apr 11, 2025, at 2:14 PM, Justin Richer via auth48archive < >>> auth48archive@rfc-editor.org> wrote: >>> >>> >>> >>> >>> >>> >>> >>>> On Apr 10, 2025, at 2:58 PM, rfc-edi...@rfc-editor.org wrote: >>> >>>> >>> >>>> Authors, >>> >>>> >>> >>>> While reviewing this document during AUTH48, please resolve (as >>> necessary) the following questions, which are also in the XML file. >>> >>>> >>> >>>> 1) <!-- [rfced] Please insert any keywords (beyond those that >>> appear in >>> >>>> the title) for use on https://www.rfc-editor.org/search. --> >>> >>>> >>> >>>> >>> >>>> 2) <!--[rfced] We changed this paragraph into smaller sentences >>> >>>> for easier reading and arranged the list of items in alphabetical >>> >>>> order. Please let us know of any objections. >>> >>>> >>> >>>> Original: >>> >>>> Terminology specific to GNAP is defined in the terminology section >>> of >>> >>>> the core specification [GNAP], and provides definitions for the >>> >>>> protocol roles: authorization server (AS), client, resource server >>> >>>> (RS), resource owner (RO), end user; as well as the protocol >>> elements: >>> >>>> attribute, access token, grant, privilege, protected resource, >>> right, >>> >>>> subject, subject information. The same definitions are used in this >>> >>>> document. >>> >>>> >>> >>>> Current: >>> >>>> Terminology specific to GNAP is defined in the terminology section >>> of >>> >>>> the core specification [GNAP]. The following protocol roles are >>> >>>> defined: authorization server (AS), client, end user, resource >>> owner (RO), >>> >>>> and resource server (RS). The following protocol elements are >>> defined: >>> >>>> access token, attribute, grant, privilege, protected resource, >>> right, >>> >>>> subject, and subject information. The same definitions are used in >>> this >>> >>>> document. >>> >>>> --> >>> >>>> >>> >>> >>> >>> This change is fine. >>> >>> >>> >>>> >>> >>>> 3) <!--[rfced] To avoid the "[JWT]" citation being used as an >>> adjective, >>> >>>> may we update "[JWT] formatted token" to "JSON-formatted token >>> >>>> [JWT]" or "JSON Web Token [JWT]" or otherwise? Note that there are >>> >>>> 9 instances in the document. >>> >>>> >>> >>>> Original: >>> >>>> In a [JWT] formatted token or a token introspection response, this >>> >>>> corresponds to the iss claim. >>> >>>> >>> >>>> Perhaps: >>> >>>> In a JSON-formatted token [JWT] or a token introspection response, >>> >>>> this corresponds to the iss claim. >>> >>>> >>> >>>> Or: >>> >>>> In a JSON Web Token [JWT] or a token introspection response, >>> >>>> this corresponds to the iss claim. >>> >>>> --> >>> >>> >>> >>> Let’s go with: >>> >>> >>> >>> In the payload of a JSON Web Token [JWT] or a token introspection >>> response, >>> >>> this corresponds to the iss claim. >>> >>> >>> >>> >>> >>>> >>> >>>> >>> >>>> 4) <!--[rfced] FYI, we updated the following text for clarity and >>> to make >>> >>>> the second sentence a complete sentence. Please review whether the >>> >>>> updates are accurate. >>> >>>> >>> >>>> Original: >>> >>>> GNAP access tokens can have multiple data flags associated with >>> them >>> >>>> that indicate special processing or considerations for the token. >>> >>>> For example, whether the token is a bearer token, or should be >>> >>>> expected to be durable across grant updates. >>> >>>> >>> >>>> Current: >>> >>>> GNAP access tokens can have multiple associated data flags that >>> >>>> indicate special processing or considerations for a token. For >>> >>>> example, the data flags can indicate whether a token is a bearer >>> >>>> token or should be expected to be durable across grant updates. >>> >>>> --> >>> >>>> >>> >>> >>> >>> The change is fine. >>> >>> >>> >>>> >>> >>>> 5) <!--[rfced] We updated "RS's" to "one or more RSs" in the >>> following >>> >>>> text. We also updated "from others usable at" to "from other >>> >>>> access tokens used at" in the first paragraph for consistency >>> >>>> with the second paragraph. Please let us know if any of these >>> >>>> changes are not correct. >>> >>>> >>> >>>> In addition, please review the remaining instances of "RS's" and >>> "AS's" >>> >>>> (singular possessive) throughout the document and let us know if any >>> >>>> occurrences are intended to be plural. We have updated a few >>> instances, >>> >>>> e.g., "targeted to different RS's" -> "targeted to different RSs". >>> >>>> >>> >>>> Original: >>> >>>> When an access token is used for the grant continuation API defined >>> >>>> in Section 5 of [GNAP] (the continuation access token) the token >>> >>>> management API defined in Section 6 of [GNAP] (the token management >>> >>>> access token), or the RS-facing API defined in Section 3 (the >>> >>>> resource server management access token), the AS MUST separate these >>> >>>> access tokens from others usable at RS's. >>> >>>> [...] >>> >>>> >>> >>>> For continuation access tokens and token management access tokens, a >>> >>>> client instance MUST take steps to differentiate these special- >>> >>>> purpose access tokens from access tokens used at RS's. >>> >>>> >>> >>>> Current: >>> >>>> When an access token is used for the grant continuation API defined >>> >>>> in Section 5 of [GNAP] (the continuation access token), the token >>> >>>> management API defined in Section 6 of [GNAP] (the token management >>> >>>> access token), or the RS-facing API defined in Section 3 (the >>> >>>> resource server management access token), the AS MUST separate these >>> >>>> access tokens from other access tokens used at one or more RSs. >>> >>>> [...] >>> >>>> >>> >>>> For continuation access tokens and token management access tokens, a >>> >>>> client instance MUST take steps to differentiate these special- >>> >>>> purpose access tokens from access tokens used at one or more RSs. >>> >>>> --> >>> >>>> >>> >>> >>> >>> These changes are fine. >>> >>> >>> >>>> >>> >>>> 6) <!-- [rfced] [GNAP] does not contain Section 3.1.2. Please let >>> us know >>> >>>> which section was intended (perhaps Section 3.2.1 ("Single Access >>> >>>> Token"). >>> >>>> >>> >>>> Original: >>> >>>> The client instance is given token management access tokens only >>> >>>> as part of the manage field of the grant response in Section 3.1.2 >>> >>>> of [GNAP]. >>> >>>> --> >>> >>>> >>> >>> >>> >>> Yes, the reference was intended to be section 3.2.1 as this defines >>> the “manage” field that is referenced here. >>> >>> >>> >>>> >>> >>>> 7) <!--[rfced] In the lists in Sections 3.1 and 3.5, we note that >>> the key >>> >>>> words (REQUIRED, OPTIONAL, etc.) are included at the end of the >>> >>>> descriptions whereas the key words are included at the beginning >>> >>>> of the descriptions in all other relevant sections. Would you >>> >>>> like to make these consistent by updating Sections 3.1 and 3.5 as >>> >>>> shown in the example below? >>> >>>> >>> >>>> One example >>> >>>> >>> >>>> Current: >>> >>>> token_formats_supported (array of strings): A list of token formats >>> >>>> supported by this AS. The values in this list MUST be registered >>> >>>> in the "GNAP Token Format Registry Formats" registry in Section >>> 5.3. >>> >>>> OPTIONAL. >>> >>>> >>> >>>> Perhaps: >>> >>>> token_formats_supported (array of strings): OPTIONAL. A list of >>> token >>> >>>> formats supported by this AS. The values in this list MUST be >>> >>>> registered in the "GNAP Token Format Registry Formats" registry >>> per >>> >>>> Section 5.3. >>> >>>> --> >>> >>>> >>> >>> >>> >>> In the companion specification, RFC9646, we seem to have usually put >>> the keywords at the end on the lists, so I think we should instead update >>> the lists in sections 3.3 (two lists) and 3.4 (two lists) to make them all >>> consistent with the normative requirements at the end. >>> >>> >>> >>>> >>> >>>> 8) <!--[rfced] Please note the mismatch here between >>> >>>> "array of strings" vs. "string". >>> >>>> >>> >>>> As both of these seem to be regarding the "GNAP Resource Set >>> Registration >>> >>>> Request Parameters" registry (as opposed to the "GNAP RS-Facing >>> Discovery >>> >>>> Document Fields" registry), should Section 3.4 be updated to >>> "string" to match >>> >>>> the registry? >>> >>>> >>> >>>> Section 3.4 >>> >>>> token_formats_supported (array of strings): >>> >>>> >>> >>>> vs. >>> >>>> >>> >>>> Section 5.6.2: >>> >>>> token_formats_supported | string | Section 3.4 >>> >>>> --> >>> >>>> >>> >>> >>> >>> Section 5.6.2 should be updated to be “array of strings” and the >>> corresponding entry in the IANA registry will need to be updated as well >>> (it currently is registered as “string” at >>> https://www.iana.org/assignments/gnap/gnap.xhtml#gnap-resource-set-registration-request-parameters >>> >>> >>> >>>> >>> >>>> 9) <!--[rfced] We are having trouble parsing the following text >>> (are some >>> >>>> words missing?). Please let us know how we may update this >>> >>>> sentence for clarity. >>> >>>> >>> >>>> Original: >>> >>>> token_formats_supported (array of strings): OPTIONAL. The token >>> >>>> formats the RS is able to process for accessing the resource. >>> >>>> >>> >>>> Perhaps: >>> >>>> token_formats_supported (array of strings): OPTIONAL. The list of >>> >>>> token formats the RS is able to process in order to access the >>> >>>> resources. >>> >>>> --> >>> >>> >>> >>> >>> >>> We can simplify to: >>> >>> >>> >>> token_formats_supported (array of strings): OPTIONAL. The list of >>> >>> token formats that the RS is able to process. >>> >>> >>> >>> >>> >>>> >>> >>>> >>> >>>> 10) <!--[rfced] We note "HTTP 400 Bad Request error" vs. "HTTP (Bad >>> >>>> Request) status code". Should this perhaps be updated as "HTTP >>> >>>> 400 (Bad Request) error code" for consistency as shown below? >>> >>>> >>> >>>> Original: >>> >>>> If the registration fails, the AS returns an HTTP 400 Bad Request >>> >>>> error to the RS indicating that the registration was not successful. >>> >>>> >>> >>>> In the case of an error from the RS-facing API, the AS responds to >>> >>>> the RS with an HTTP 400 (Bad Request) status code and a JSON object >>> >>>> consisting of a single error field, which is either an object or a >>> >>>> string. >>> >>>> >>> >>>> Perhaps: >>> >>>> If the registration fails, the AS returns an HTTP 400 (Bad Request) >>> >>>> error code to the RS indicating that the registration was not >>> >>>> successful. >>> >>>> >>> >>>> In the case of an error from the RS-facing API, the AS responds to >>> >>>> the RS with an HTTP 400 (Bad Request) error code and a JSON object >>> >>>> consisting of a single error field, which is either an object or a >>> >>>> string. >>> >>>> --> >>> >>>> >>> >>> >>> >>> From my understanding of the HTTP style guidelines, these instances >>> should be: >>> >>> >>> >>> … returns HTTP status code 400 (Bad Request) to the RS ... >>> >>> >>> >>> … the RS with HTTP status code 400 (Bad Request) and a … >>> >>> >>> >>>> >>> >>>> 11) <!--[rfced] FYI, for the sourcecode element in Section 4, >>> >>>> two spaces were removed from the left side of the access_token >>> >>>> so that it fits the line-length restriction. Please let us know >>> >>>> if you prefer otherwise. >>> >>>> >>> >>>> This line was previously too long: >>> >>>> "existing_access_token": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0" >>> >>>> --> >>> >>>> >>> >>> >>> >>> I don’t actually see this change in the source or in the rendered >>> text, but as long as it does not change the relative indentation/formatting >>> of the JSON element in the HTTP request, that should be fine. We can also >>> shave a few characters off of the access token value without affecting the >>> utility of the example. If we do this, we should also change the value in >>> section 3.3 — even though the examples are not directly connected to each >>> other, it was intentional that they use a consistent value. >>> >>> >>> >>>> >>> >>>> 12) <!--[rfced] Regarding variations of "string/object" >>> >>>> in the "GNAP Token Introspection Request" registry. >>> >>>> >>> >>>> a) In Table 2 (which corresponds to >>> >>>> >>> https://www.iana.org/assignments/gnap/gnap.xhtml#gnap-token-introspection-request >>> ) >>> >>>> would you like to change this type from >>> >>>> "object/string" to "string/object" to match the form of the >>> subsequent item? >>> >>>> If so, we will ask IANA to update the registry accordingly. >>> >>>> >>> >>>> Original: >>> >>>> resource_server object/string Section 3.3 of RFC >>> xxxx >>> >>>> >>> >>>> access array of strings/objects Section 3.3 of RFC >>> xxxx >>> >>>> >>> >>>> >>> >>>> Perhaps: >>> >>>> resource_server string/object Section 3.3 of RFC >>> 9767 >>> >>>> >>> >>>> access array of strings/objects Section 3.3 of RFC >>> 9767 >>> >>> >>> >>> No, this should remain as written, “object/string” and “array of >>> strings/objects”. >>> >>> >>> >>>> >>> >>>> b) Similarly, in Section 3.3, would you like to change >>> >>>> "string or object" to "string/object"? >>> >>>> (Note: If you decide not to change the original "object/string" >>> above, >>> >>>> then we will update "string or object" to "object/string" to >>> >>>> match.) >>> >>>> >>> >>>> Original: >>> >>>> resource_server (string or object): REQUIRED. ... >>> >>>> >>> >>>> access (array of strings/objects): OPTIONAL. ... >>> >>>> >>> >>>> >>> >>>> Perhaps: >>> >>>> resource_server (string/object): REQUIRED. ... >>> >>>> >>> >>>> access (array of strings/objects): OPTIONAL. ... >>> >>>> --> >>> >>>> >>> >>> >>> >>> This should be: >>> >>> >>> >>> resource_server (object/string): ... >>> >>> >>> >>> And the IANA registry should be updated. >>> >>> >>> >>>> >>> >>>> 13) <!--[rfced] Regarding variations of "string/object" >>> >>>> in the "GNAP Token Introspection Response" >>> >>>> and "GNAP Resource Set Registration Request Parameters" registries. >>> >>>> >>> >>>> a) In Table 3, would you like to change "object/string" >>> >>>> to "string/object" to match usage in the preceding item? >>> >>>> If so, we will ask IANA to update the registry ( >>> https://www.iana.org/assignments/gnap/gnap.xhtml#gnap-token-introspection-response) >>> accordingly. >>> >>>> >>> >>>> Original: >>> >>>> | access | array of strings/objects | Section 3.3 of RFC xxxx | >>> >>>> | key | object/string | Section 3.3 of RFC xxxx | >>> >>>> >>> >>>> Perhaps: >>> >>>> | access | array of strings/objects | Section 3.3 of RFC 9767 | >>> >>>> | key | string/object | Section 3.3 of RFC 9767 | >>> >>>> >>> >>>> >>> >>>> b) Similarly, in Section 3.3, would you like to change >>> "object/string" >>> >>>> to "string/object" to match usage in the preceding item? >>> >>>> >>> >>>> Original: >>> >>>> key (object/string): REQUIRED if ... >>> >>>> >>> >>>> Perhaps: >>> >>>> key (string/object): REQUIRED if ... >>> >>>> >>> >>> >>> >>> No, these should remain “object/string” and “array of >>> strings/objects” as written. >>> >>> >>> >>>> >>> >>>> c) With the same rationale, in Section 3.4 (and Table 4), would you >>> like >>> >>>> to change this as follows? If so, we will ask IANA to update the >>> registry >>> >>>> ( >>> https://www.iana.org/assignments/gnap/gnap.xhtml#gnap-resource-set-registration-request-parameters) >>> accordingly. >>> >>>> >>> >>>> Original: resource_server (string or object) >>> >>>> >>> >>>> Perhaps: resource_server (string/object) >>> >>>> --> >>> >>>> >>> >>> >>> >>> This should be: >>> >>> >>> >>> resource_server (object/string) >>> >>> >>> >>> >>> >>> as above. The IANA registry should be updated accordingly. >>> >>> >>> >>>> >>> >>>> 14) <!--[rfced] May we update this sentence for clarity? >>> >>>> >>> >>>> Original: >>> >>>> The contents of the access token model divulge to the RS information >>> >>>> about the access token's context and rights. >>> >>>> >>> >>>> Perhaps: >>> >>>> The contents of the access token model, which contains information >>> >>>> about the access token's context and rights, are divulged to the >>> RS. >>> >>>> --> >>> >>>> >>> >>> >>> >>> Perhaps instead: >>> >>> >>> >>> The contents of the access token model divulge information about the >>> access token’s context and rights to the RS. >>> >>> >>> >>> >>> >>>> >>> >>>> 15) <!--[rfced] Would using "certain circumstances" in place of >>> "limited >>> >>>> circumstances" be better to avoid the redundancy of "limiting" and >>> >>>> "limited" as shown below? >>> >>>> >>> >>>> Original: >>> >>>> Furthermore, limiting the use of bearer tokens and AS-provided keys >>> >>>> to only highly trusted AS's ASs and limited circumstances prevents >>> the >>> >>>> attacker from being able to willingly exfiltrate their token to an >>> >>>> unsuspecting client instance. >>> >>>> >>> >>>> Perhaps: >>> >>>> Furthermore, limiting the use of bearer tokens and AS-provided keys >>> >>>> to only highly trusted ASs and certain circumstances prevents the >>> >>>> attacker from being able to willingly exfiltrate their token to an >>> >>>> unsuspecting client instance. >>> >>>> --> >>> >>>> >>> >>> >>> >>> I think instead we can say: >>> >>> >>> >>> Furthermore, limiting the use of bearer tokens and AS-provided keys >>> >>> to only highly trusted ASs in certain circumstances prevents the >>> >>> attacker from being able to willingly exfiltrate their token to an >>> >>> unsuspecting client instance. >>> >>> >>> >>> >>> >>>> >>> >>>> 16) <!-- [rfced] The URL <https://www.ndss-symposium.org/ndss2014/ >>> >>>> ndss-2014-programme/macaroons-cookies-contextual-caveats- >>> >>>> decentralized-authorization-cloud/> provides an open-access link >>> >>>> to this symposium paper and is where the DOI for this paper >>> >>>> directs. May we replace the original URL with this URL as >>> >>>> shown below? >>> >>>> >>> >>>> Current: >>> >>>> [MACAROON] Birgisson, A., Politz, J. G., Erlingsson, U., Taly, A., >>> >>>> Vrable, M., and M. Lentczner, "Macaroons: Cookies with >>> >>>> Contextual Caveats for Decentralized Authorization in the >>> >>>> Cloud", NDSS Symposium 2014, DOI >>> 10.14722/ndss.2014.23212, >>> >>>> February 2014, <https://research.google/pubs/pub41892/>. >>> >>>> >>> >>>> Perhaps: >>> >>>> [MACAROON] Birgisson, A., Politz, J. G., Erlingsson, U., Taly, A., >>> >>>> Vrable, M., and M. Lentczner, "Macaroons: Cookies with >>> >>>> Contextual Caveats for Decentralized Authorization in the >>> >>>> Cloud", NDSS Symposium 2014, DOI >>> 10.14722/ndss.2014.23212, >>> >>>> February 2014, <https://www.ndss-symposium.org/ndss2014/ >>> >>>> ndss-2014-programme/macaroons-cookies-contextual-caveats- >>> >>>> decentralized-authorization-cloud/>. >>> >>>> --> >>> >>>> >>> >>> >>> >>> This change is fine - whatever the best URL is for the reference. I >>> am not able to find another RFC that references the Macaroon format. >>> >>> >>> >>>> >>> >>>> 17) <!-- [rfced] FYI: To match other usage in the document, we >>> updated the first >>> >>>> artwork element in Section 3.2 to sourcecode and set the type to >>> >>>> "http-message". Please let us know if we need to update otherwise. >>> >>>> >>> >>>> Additionally, please review the "type" attribute of each sourcecode >>> element >>> >>>> in the XML file to ensure correctness. If the current list of >>> preferred >>> >>>> values for "type" >>> >>>> (https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types) >>> >>>> does not contain an applicable type, then feel free to let us know. >>> >>>> Also, it is acceptable to leave the "type" attribute not set. >>> >>>> --> >>> >>>> >>> >>> >>> >>> Yes, these look good. >>> >>> >>> >>>> >>> >>>> 18) <!-- [rfced] Please review usage of <tt> and <em> in this >>> document >>> >>>> and let us know if any updates are needed. >>> >>>> >>> >>>> In the HTML and PDF outputs, the text enclosed in <tt> is output >>> >>>> in fixed-width font. In the TXT output, there are no changes to the >>> font, >>> >>>> and quotation marks are not generated. >>> >>>> >>> >>>> In the HTML and PDF outputs, the text enclosed in <em> is output in >>> >>>> italics. In the TXT output, the text enclosed in <em> appears with >>> an >>> >>>> underscore before and after. This is used only in Section 2.1.1. >>> >>>> --> >>> >>>> >>> >>> >>> >>> Yes, these look good. >>> >>> >>> >>>> >>> >>>> 19) <!-- [rfced] Please review the "Inclusive Language" portion of >>> the online >>> >>>> Style Guide < >>> https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >>> >>>> and let us know if any changes are needed. Updates of this nature >>> typically >>> >>>> result in more precise language, which is helpful for readers. >>> >>>> >>> >>>> Note that our script did not flag any words in particular, but this >>> should >>> >>>> still be reviewed as a best practice. >>> >>>> --> >>> >>>> >>> >>> >>> >>> I believe we have followed best practice for this language. >>> >>> >>> >>>> >>> >>>> Thank you. >>> >>>> >>> >>>> RFC Editor/kc/ar >>> >>>> >>> >>> >>> >>> >>> >>> I believe with these changes implemented we should be ready to >>> publish. >>> >>> >>> >>> — Justin >>> >>> >>> >>>> >>> >>>> On Apr 10, 2025, rfc-edi...@rfc-editor.org wrote: >>> >>>> >>> >>>> *****IMPORTANT***** >>> >>>> >>> >>>> Updated 2025/04/10 >>> >>>> >>> >>>> 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 >>> >>>> >>> >>>> * rfc-edi...@rfc-editor.org (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). >>> >>>> >>> >>>> * auth48archive@rfc-editor.org, 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, >>> >>>> auth48archive@rfc-editor.org 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/rfc9767.xml >>> >>>> https://www.rfc-editor.org/authors/rfc9767.html >>> >>>> https://www.rfc-editor.org/authors/rfc9767.pdf >>> >>>> https://www.rfc-editor.org/authors/rfc9767.txt >>> >>>> >>> >>>> Diff file of the text: >>> >>>> https://www.rfc-editor.org/authors/rfc9767-diff.html >>> >>>> https://www.rfc-editor.org/authors/rfc9767-rfcdiff.html (side by >>> side) >>> >>>> >>> >>>> Diff of the XML: >>> >>>> https://www.rfc-editor.org/authors/rfc9767-xmldiff1.html >>> >>>> >>> >>>> >>> >>>> Tracking progress >>> >>>> ----------------- >>> >>>> >>> >>>> The details of the AUTH48 status of your document are here: >>> >>>> https://www.rfc-editor.org/auth48/rfc9767 >>> >>>> >>> >>>> Please let us know if you have any questions. >>> >>>> >>> >>>> Thank you for your cooperation, >>> >>>> >>> >>>> RFC Editor >>> >>>> >>> >>>> -------------------------------------- >>> >>>> RFC9767 (draft-ietf-gnap-resource-servers-09) >>> >>>> >>> >>>> Title : Grant Negotiation and Authorization Protocol >>> Resource Server Connections >>> >>>> Author(s) : J. Richer, Ed., F. Imbault >>> >>>> WG Chair(s) : Yaron Sheffer, Leif Johansson >>> >>>> Area Director(s) : Deb Cooley, Paul Wouters >>> >>> >>> >>> -- >>> >>> auth48archive mailing list -- auth48archive@rfc-editor.org >>> >>> To unsubscribe send an email to auth48archive-le...@rfc-editor.org >>> >> >>> > >>> >>> >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
