Hi Karen, hi Justin,

That's good, thanks a lot.

Best regards
Fabien

On Wed, 16 Apr 2025, 22:01 Karen Moore, <kmo...@staff.rfc-editor.org> wrote:

> Hi Justin,
>
> We have noted your approval on the AUTH48 status page for this document (
> https://www.rfc-editor.org/auth48/rfc9767).  We now await Fabien’s
> approval prior to moving forward with the publication process.
>
> Additionally, please let us know if you would like to add any keywords
> (beyond those that appear in the title) for use on
> https://www.rfc-editor.org/search.
>
> Best regards,
> RFC Editor/kc
>
> > On Apr 16, 2025, at 9:40 AM, Justin Richer <jric...@mit.edu> wrote:
> >
> > All,
> >
> > I’ve read through the changes and I approve this version of the document
> for final publication.
> >
> > Fabien, please review (especially the final diff at
> https://www.rfc-editor.org/authors/rfc9767-rfcdiff.html) and let us know
> where you stand on the changes and content.
> >
> > Thank you, everyone.
> >
> >  — Justin
> >
> >> On Apr 14, 2025, at 1:55 PM, 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

Reply via email to