OK, I think the best bet is to keep the acert.io<http://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<mailto: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<mailto:fabien.imba...@gmail.com> if needed. Best regards Fabien On Mon, 14 Apr 2025, 21:06 Justin Richer, <jric...@mit.edu<mailto: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<mailto:kmo...@staff.rfc-editor.org>> wrote: > > Hi Justin, > > We received a bounced message for > fabien.imba...@acert.io<mailto: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<mailto: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<mailto:auth48archive@rfc-editor.org>> wrote: >>> >>> >>> >>>> On Apr 10, 2025, at 2:58 PM, >>>> rfc-edi...@rfc-editor.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:auth48archive@rfc-editor.org> >>> To unsubscribe send an email to >>> auth48archive-le...@rfc-editor.org<mailto:auth48archive-le...@rfc-editor.org> >> >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
