Hi Marco and *Paul, [*Paul - please review the updates the authors made in response to our question 21 (regarding the BCP 14 language) and confirm no further updates are necessary.]
Thank you for your reply and guidance. We have updated accordingly. Just a follow up to our question: >>> 25) <!-- [rfced] We note that Appendices D and E were tagged "removeInRFC" >>> in the XML. We have removed Appendix E (change log) but left >>> Appendix D as it has citations to it in the text. Please review >>> and let us know if any further updates are necessary. --> >>> >> >> ==>MT >> >> The intention was to eventually remove Appendix D too, after having applied >> the "Note to RFC Editor" in the last paragraph of Section 1.1. In order to remove Appendix D, the following text in the Introduction would need to be changed: In the CBOR diagnostic notation used in this document, constructs of the form e'SOME_NAME' are replaced by the value assigned to SOME_NAME in the CDDL model shown in Figure 15 of Appendix D. - and - Also, in the CBOR diagnostic notation used in this document, please replace the constructs of the form e'SOME_NAME' with the value assigned to SOME_NAME in the CDDL model shown in Figure 15 of Appendix D. Please review and let us know how you would like to proceed. Please review the files carefully as we do not make changes after publication. The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9770.txt https://www.rfc-editor.org/authors/rfc9770.pdf https://www.rfc-editor.org/authors/rfc9770.html https://www.rfc-editor.org/authors/rfc9770.xml The relevant diff files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9770-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9770-auth48diff.html (AUTH48 changes only) https://www.rfc-editor.org/authors/rfc9770-lastdiff.html (last to current version only) Please contact us with any further updates/questions/comments you may have. We will await approvals from each of the parties listed on the AUTH48 status page prior to moving forward to publication. The AUTH48 status page for this document is available here: https://www.rfc-editor.org/auth48/rfc9770 Thank you. RFC Editor/mf > On Apr 30, 2025, at 5:57 AM, Marco Tiloca > <marco.tiloca=40ri...@dmarc.ietf.org> wrote: > > Dear RFC Editor, > > Please find below the answers to your questions on behalf of the whole author > team. > > Once the next edited version is available, I will make a full review of it. > > Thanks, > /Marco > > On 2025-04-15 04:12, rfc-edi...@rfc-editor.org wrote: >> Authors and *AD, >> >> [AD - please review and weigh in on Question 21.] >> >> 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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fsearch&data=05%7C02%7Cmarco.tiloca%40ri.se%7C10670f445e4a4d98ba0a08dd7bc32c79%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638802800666304614%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=tsyLyxvHg19vnUWwoLv%2FJhUOpgj%2FTdlILMaA2jMjSzw%3D&reserved=0. >> --> > > ==>MT > > Security; Access control; Access rights; Revocation; CoAP; IoT; Constrained > environments > > <== > >> >> >> 2) <!--[rfced] Please review the use of "and" before list item 5: should >> this instead be "or"? >> >> Original: >> Even though access tokens have expiration times, there are >> circumstances by which an access token may need to be revoked before >> its expiration time, such as: (1) a registered device has been >> compromised, or is suspected of being compromised; (2) a registered >> device is decommissioned; (3) there has been a change in the ACE >> profile for a registered device; (4) there has been a change in >> access policies for a registered device; and (5) there has been a >> change in the outcome of policy evaluation for a registered device >> (e.g., if policy assessment depends on dynamic conditions in the >> execution environment, the user context, or the resource >> utilization). >> >> --> >> > > ==>MT > > Yes, the suggested change is right. So it should be: > > OLD: > ... for a registered device; and (5) there has been ... > > NEW: > ... for a registered device; or (5) there has been ... > > <== > >> >> >> 3) <!--[rfced] Were we to expand this abbreviation, this text might be >> redundant. Please let us know if/how to update. >> >> Original: >> ...used in the ACE framework for Authentication and Authorization. >> >> As expanded, this reads as: >> ...used in the Authentication and Authorization for Constrained >> Environments framework for Authentication and Authorization. >> >> Original: >> ... described in the ACE framework for Authentication and Authorization >> [RFC9200 >> ]... >> >> --> >> > > ==>MT > > Actually, "ACE" is already expanded in the first sentence of Section 1. So I > propose to do the following trimming in 7 instances: > > OLD: > ACE framework for Authentication and Authorization > > NEW: > ACE framework > > The 7 instances to trim are in: > > * Section 1.0, in the paragraph starting with "This document specifies a > method" > > * Section 1.1, in the paragraph starting with "Readers are expected" > > * Section 3, in the paragraph starting with "Consistent with the ACE > framework" > > * Section 4.1, in the paragraph starting with "An access token can have one > among" > > * Section 10, in the paragraph starting with "Further details about the > registration" > > * Section 14.0, in the paragraph starting with "The protocol defined in this > document" > > * Section 14.7, in the paragraph starting with "Conversely, this design > deliberately" > > <== > >> >> >> 4) <!--[rfced] Please confirm that our suggested edit captures your >> intent. >> >> Original: >> It is also out of scope the method by which the AS determines or is >> notified of revoked access tokens, according to which the AS >> consequently updates the TRL as specified in this document. >> >> Perhaps: >> The method by which the AS determines or is notified of revoked access >> tokens, according to which the AS consequently updates the TRL as >> specified in this document, is also out of scope. >> >> --> >> > > ==>MT > > Confirmed. The suggested new phrasing is good. > > <== > >> >> >> 5) <!--[rfced] In the following, should a reference to RFC 7252 be added >> for the direct quote? This is the first occurrence of this text >> in an RFC. >> >> Original: >> This document does not use the CoAP definition of "endpoint", which is >> "An entity participating in the CoAP protocol. >> " >> >> Perhaps: >> This document does not use the CoAP definition of " >> endpoint", which is >> defined in [RFC7252] as "An entity participating in the CoAP protocol." >> >> --> >> > > ==>MT > > It is better to add a reference to RFC 7252. At the same time, other RFCs are > conveying the same message, with a more accurate and slightly different > phrasing. For example: > > * In RFC 9200, Section 2, 5th paragraph: > > > The CoAP definition, which is "[a]n entity participating in the CoAP > protocol" [RFC7252], is not used in this specification. > > * In RFC 9203, Section 1.1, 7th paragraph: > > > The CoAP definition, which is "[a]n entity participating in the CoAP > protocol" [RFC7252], is not used in this document. > > In order to also be consistent with those RFCs, I suggest the following > rephrasing. > > OLD: > This document does not use the CoAP definition of "endpoint", which is "An > entity participating in the CoAP protocol." > > NEW: > The CoAP definition, which is "[a]n entity participating in the CoAP > protocol" [RFC7252], is not used in this document. > > <== > >> >> >> 6) <!--[rfced] Does the following rephrase capture your intended meaning? >> >> Original: >> By doing so, the registered device effectively subscribes to the TRL, >> as interested in receiving notifications about its update. >> >> Perhaps: >> By doing so, the registered device effectively subscribes to the TRL, >> as the device is interested in receiving notifications about the TRL's >> update. >> --> >> > > ==>MT > > Confirmed. The suggested new phrasing is good. > > <== > >> >> >> 7) <!--[rfced] We are unable to parse "and to which the access token >> pertains". Please rephrase. >> >> Original: >> That is, an Observe notification is sent to each registered device >> subscribed to the TRL and to which the access token pertains. >> >> --> >> > > ==>MT > > The intended meaning is as follows. Given a revoked access token, a device is > targeted by notifications about that access token if that device is both: i) > subscribed to the TRL; and ii) the access token pertains to that device (per > the definition of "pertaining access token" in Section 1.1). > > For this "Protocol Overview" section, the following simple rephrasing is > hopefully good enough. > > OLD > That is, an Observe notification is sent to each registered device subscribed > to the TRL and to which the access token pertains. > > NEW > That is, an Observe notification is sent to each registered device that is > subscribed to the TRL and to which the access token pertains. > > <== > >> >> >> 8) <!--[rfced] Please review the addition of "either" and let us know if >> this edit correctly captures your intent. >> >> Original: >> Depending on the specific subscription established through the >> Observation Request, the notification provides the current >> updated list of revoked access tokens in the subset of the TRL >> pertaining to that device (see Section 7), or the most recent TRL >> updates occurred over that list of pertaining revoked access >> tokens (see Section 8). >> >> Perhaps: >> Depending on the specific subscription established through the >> Observation Request, the notification provides either the current >> updated list of revoked access tokens in the subset of the TRL >> pertaining to that device (see Section 7) or the most recent TRL >> updates that occurred over that list of pertaining revoked access >> tokens (see Section 8). >> >> --> >> > > ==>MT > > Confirmed. The suggested new phrasing is good as also including the word > "either". > > <== > >> >> >> 9) <!--[rfced] We noticed repetition of the word "tag" in the following >> sentence. Does this rephrase correctly capture your intent? >> >> Original: >> In turn, the resulting tagged data item MUST be tagged by using >> the CWT CBOR tag with tag number 61 (see Section 6 of >> [RFC8392]). >> >> Perhaps: >> In turn, the resulting data item MUST be tagged using >> CWT CBOR tag number 61 (see Section 6 of [RFC8392]). >> --> >> > > ==>MT > > Please keep the original text, as it is correct and more consistent with the > parlance of RFC 8949 and RFC 8392. In particular, Section 2 of RFC 8949 says: > > > In the basic (unextended) generic data model defined in Section 3, a data > > item is one of the following: > > > > ... > > > > * a tagged data item ("tag"), comprising a tag number (an integer in the > > range 0..264-1) and the tag content (a data item) > > That is, a data item X can be tagged. The result is a new data item Y, i.e., > a tag, which is composed of a tag number together with a tag content (the > data item X). > > As also summarized in Section 4 of the present document: > > > Consistent with Section 3.4 of [RFC8949], the term "tag" is used for the > > entire CBOR data item consisting of both a tag number and the tag content: > > the tag content is the CBOR data item that is being tagged. > > <== > >> >> >> 10) <!--[rfced] Much of Section 4 describes terminology. Should a pointer >> to this section be added to the Terminology section? >> >> Perhaps: >> See Section 4 for further terminology used throughout that section. >> >> --> >> > > ==>MT > > Good idea. This sentence can fit well in Section 1.1 right before the > paragraph starting with "Examples throughout this document are expressed ...". > > <== > >> >> >> 11) <!--[rfced] Does this rephrase capture your intended meaning? >> >> Original: >> An access token can have one among different formats. >> >> Perhaps: >> There are different formats an access token can have. >> --> >> > > ==>MT > > I would prefer to keep the original phrasing. It unambiguously conveys the > idea that an issued access token has a single format from an available set of > formats. > > <== > >> >> >> 12) <!--[rfced] We note that the sub-bullets in Section 4.1.1 reverse >> order (i.e., the first bullet has CWT and then JWT mentioned in >> the sub-bullets and the second bullet lists JWT and then CWT in >> the sub-bullets). Please confirm that this is intentional or let >> us know if you'd like them to appear in the same order in both >> places.--> >> > > ==>MT > > Please keep the current order, which is intentional. For the first message > encoding method using CBOR, the idea was to mention first the CBOR-based > format CWT. Similarly, for the second message encoding method using JSON, the > idea was to mention first the JSON-based format JWT. > > <== > >> >> >> 13) <!--[rfced] When "tagged" appears in parentheses, should the reader >> assume this means "either tagged or not tagged"? For example: >> >> Original: >> That is, TOKEN_INFO is the binary representation of the (tagged) >> access token. >> >> Perhaps: >> That is, TOKEN_INFO is the binary representation of the tagged >> access token (whether or not it is tagged). >> --> >> > > ==>MT > > Generally speaking, the "access token" can be tagged or not, but it is not > fully about freedom of choice here. The "tags" used in this document are > specifically CBOR tags. If the access token is a CWT (hence, encoded in > CBOR), it must always be tagged as specified in Section 3. If the access > token is a JWT (hence, encoded in JSON), there is no applicable tagging. > > The intention of the text was to encompass: i) JWTs, which are not tagged; > ii) CWTs, which are always tagged and always in a precise way for this > protocol; iii) other future formats of access token that, if based on CBOR, > might be tagged. > > At the same time, the expression "(tagged) access token" is used 6 times in > Section 4.1.2 and one more time in Section 4.2. > > In order to be clearer but also avoid redundancy, I propose the following > changes in those two sections. > > * Section 4.1.2 > > First, we drop the 6 occurrences of "(tagged)". > > Also, we add the following new paragraph at the end of the section, after > the bullet list: > > NEW: > Note that, if the access token is a CWT, it is specifically tagged as > defined in Section 3 of this document. > > * Section 4.2 > > The first paragraph can drop the word "(tagged)" and be extended with one > more sentence, as follows. > > OLD: > The client and the AS consider the content of the 'access_token' parameter > in the AS-to-Client response, in which the (tagged) access token is included > and provided to the requester client. > > NEW: > The client and the AS consider the content of the 'access_token' parameter > in the AS-to-Client response, in which the access token is included and > provided to the requester client. Note that, if the access token is a CWT, it > is specifically tagged as defined in Section 3 of this document. > > <== > >> >> >> 14) <!--[rfced] Please confirm that commas should not separate these >> values in curly brackets: >> >> Original: >> With reference to the example in Figure 3, BYTES is the bytes >> {0xd8 0x3d 0xd0 ... 0x64 0x3b}. >> --> >> > > ==>MT > > I think it's actually good to have commas separating the different bytes. > > OLD: > {0xd8 0x3d 0xd0 ... 0x64 0x3b} > > NEW: > {0xd8, 0x3d, 0xd0, ..., 0x64, 0x3b} > > <== > >> >> >> 15) <!--[rfced] These sentences do not parse. Please review "with value >> the token hash" in particular. >> >> Original: >> Each element of the array is a CBOR byte string, with value the token >> hash of an access token. >> >> Original: >> Each element of the array is a CBOR byte string, with value the >> token hash of an access token such that: it pertained to the >> requester; and it was removed from the TRL during the update >> associated with the diff entry. >> --> >> > > ==>MT > > There are overall 4 instances of "with value the token hash" or "with value > the token hashes" in the document. Like in RFC 9594, I suggest to change them > to say "whose value is". Specifically: > > * Section 5 > > OLD: > Each element of the array is a CBOR byte string with value the token hash > of an access token. > > NEW: > Each element of the array is a CBOR byte string, whose value is the token > hash of an access token. > > * Section 8 > > OLD: > a. ... Each element of the array is a CBOR byte string with value the token > hash of an access token such that ... > > NEW: > a. ... Each element of the array is a CBOR byte string, whose value is the > token hash of an access token such that ... > > * Section 8 > > OLD: > b. ... Each element of the array is a CBOR byte string with value the token > hash of an access token such that ... > > NEW: > b. ... Each element of the array is a CBOR byte string, whose value is the > token hash of an access token such that ... > > * Appendix C > > OLD: > ... denote the CBOR byte strings with value the token hashes of the access > tokens ... > > NEW: > ... denote the CBOR byte strings whose values are the token hashes of the > access tokens ... > > <== > >> >> >> 16) <!--[rfced] The double prepositions (between and towards) make this >> text hard to parse. How may we rephrase? >> >> Original: >> Consistent with Section 6.5 of [RFC9200], all communications between >> a requester towards the TRL endpoint and the AS MUST be encrypted, as >> well as integrity and replay protected. >> >> --> >> > > ==>MT > > I suggest to rephrase as below: > > NEW: > Consistent with Section 6.5 of [RFC9200], all communications between the AS > and a requester interacting with the TRL endpoint at the AS MUST be > encrypted, as well as integrity and replay protected. > > <== > >> >> >> 17) <!--[rfced] Please review the following text and let us know what >> "trl_patch" names? Is this the name of the sets? The token >> hashes? >> >> Original: >> >> 2. The AS creates two sets "trl_patch" of token hashes, i.e., one >> "removed" set and one "added" set, as related to this TRL update. >> >> Perhaps: >> >> 2. The AS creates two sets of "trl_patch" token hashes, i.e., one >> "removed" set and one "added" set, as related to this TRL update. >> >> >> --> >> > > ==>MT > > Sorry for the confusion. trl_patch is intended to be a type of set, while > "removed" and "added" are names given to two exact sets of that type. > > These concepts come back later in Section 8, both within Step 3 and in Figure > 8. Also for consistency with the use of single/double quotes, I propose the > following fixes. > > * Section 6.2 > > OLD: > 2. The AS creates two sets "trl_patch" of token hashes, i.e., one "removed" > set and one "added" set, as related to this TRL update. > > NEW: > 2. The AS creates two trl_patch sets of token hashes, i.e., one 'removed' > set and one 'added' set, as related to this TRL update. > > * Section 8 > > OLD > a. A 'trl_patch' set of token hashes encoded ... > > NEW > a. A trl_patch set of token hashes encoded ... > > * Section 8 > > OLD > b. A 'trl_patch' set of token hashes encoded ... > > NEW > b. A trl_patch set of token hashes encoded ... > > <== > >> >> >> 18) <!--[rfced] Please clarify what "it" refers to in the following: >> >> Original: >> >> - All of the following hold: the update collection associated >> with the requester is not empty; no wrap-around of its 'index' >> value has occurred; and the 'cursor' query parameter has a >> value strictly greater than the current 'last_index' on the >> update collection (see Section 6.2.1). >> >> --> >> > > ==>MT > > There is no occurrence of "it" in the quoted text, so I suppose that the > comment refers to "its". > > The idea was to simply refer to the whole pool of values used as 'index', > with each value consumed by one series item of the update collection in > question. > > The word "its" can be better and safely replaced with "the", thus using the > same phrasing used, e.g., in Section 6.2.1, which says: > > > As long as a wraparound of the 'index' value has not occurred, ... > > So, the new text in the considered Section 6.3 can say: > > NEW: > ... is not empty; no wrap-around of the 'index' value has occurred; ... > > <== > >> >> >> 19) <!--[rfced] This sentence doesn't parse. Please rephrase especially >> the part with "with value the token hash of an access token". >> Note similar text is in both bullets under number 3 in Section 8. >> Please let us know if the same fix may be applied in both places >> or if different changes are required. >> >> Original: >> Each element of the array is a CBOR byte string, with value the token >> hash of an access token such that: it pertained to the requester; and >> it was removed from the TRL during the update associated with the diff >> entry. >> >> --> >> > > ==>MT > > Like suggested the response to question 15, please make the following changes > in the considered Section 8. (Like described in the response to question 15, > a similar fix applies to Appendix C.) > > * Section 8 > > OLD: > a. ... Each element of the array is a CBOR byte string with value the token > hash of an access token such that ... > > NEW: > a. ... Each element of the array is a CBOR byte string, whose value is the > token hash of an access token such that ... > > * Section 8 > > OLD: > b. ... Each element of the array is a CBOR byte string with value the token > hash of an access token such that ... > > NEW: > b. ... Each element of the array is a CBOR byte string, whose value is the > token hash of an access token such that ... > > <== > >> >> >> 20) <!--[rfced] Please confirm our update to use the antecedent instead of >> "This" for clarity. >> >> Original: >> Otherwise, the 'cursor' parameter MUST specify a CBOR unsigned >> integer. This MUST take the 'index' value of the last series item in >> the update collection associated with the requester (see Section >> 6.2.1), as corresponding to the most recent TRL update pertaining to >> the requester. >> >> Perhaps: >> Otherwise, the 'cursor' parameter MUST specify a CBOR unsigned >> integer. This integer MUST take the 'index' value of the last series item in >> the update collection associated with the requester (see Section >> 6.2.1) as corresponding to the most recent TRL update pertaining to >> the requester. >> >> --> >> > > ==>MT > > I would be even more specific and say: > > NEW: > The unsigned integer MUST take ... > > <== > >> >> >> 21) <!--[rfced] *ADs - please review the following sentences that may lead >> to two interpretations of what the BCP 14 language applies to >> (due to the use of "and"). If the suggested text is not >> accurate, we suggest breaking up these sentences or rewording for >> clarity. Note that some of the following sentences appear in >> more than one location. >> >> Original: >> >> * The 'diff_set' parameter MUST be included and specifies the empty >> CBOR array. >> >> * The 'cursor' parameter MUST be included and specifies the CBOR >> simple value null (0xf6). >> >> * The 'more' parameter MUST be included and specifies the CBOR >> simple value false (0xf4). >> >> Perhaps: >> >> >> * The 'diff_set' parameter MUST be included and MUST specify the empty >> CBOR array. >> >> * The 'cursor' parameter MUST be included and MUST specify the CBOR >> simple value null (0xf6). >> >> * The 'more' parameter MUST be included and MUST specify the CBOR >> simple value false (0xf4). >> >> >> Original: >> * The 'full_set' parameter MUST be included and specifies a CBOR >> array 'full_set_value'. >> >> Perhaps: >> * The 'full_set' parameter MUST be included and MUST specify a CBOR >> array 'full_set_value'. >> >> Original: >> * The 'diff_set' parameter MUST be present and specifies a CBOR >> array 'diff_set_value' of U elements. >> >> Perhaps: >> * The 'diff_set' parameter MUST be present and MUST specify a CBOR >> array 'diff_set_value' of U elements. >> >> Original: >> * The 'diff_set' parameter MUST be present and specifies a CBOR >> array 'diff_set_value' of U elements. >> >> Perhaps: >> * The 'diff_set' parameter MUST be present and MUST specify a CBOR >> array 'diff_set_value' of U elements. >> >> Original: >> >> - The 'cursor' parameter MUST be present and specifies a CBOR >> unsigned integer. >> >> Perhaps: >> - The 'cursor' parameter MUST be present and MUST specify a CBOR >> unsigned integer. >> >> Original: >> - The 'more' parameter MUST be present and MUST specify the CBOR >> simple value false (0xf4) if U <= MAX_DIFF_BATCH, or the CBOR >> simple value true (0xf5) otherwise. >> >> Perhaps: >> - The 'more' parameter MUST be present and MUST specify the CBOR >> simple value false (0xf4) if U <= MAX_DIFF_BATCH; otherwise, it >> MUST specify the CBOR simple value true (0xf5). >> >> Original: >> o The 'more' parameter MUST be present and MUST specify the >> CBOR simple value false (0xf4) if SUB_U <= MAX_DIFF_BATCH, >> or the CBOR simple value true (0xf5) otherwise. >> >> Perhaps: >> o The 'more' parameter MUST be present and MUST specify the >> CBOR simple value false (0xf4) if SUB_U <= MAX_DIFF_BATCH; >> otherwise, it MUST specify the CBOR simple value true (0xf5). >> >> >> --> >> > > ==>MT > > The general intent was to be normative as to both the inclusion of a > parameter and its type or conveyed value, so it is fine to use the two > separate "MUST". However, we prefer to avoid the wording "MUST specify" when > stating the value, and instead use "MUST encode". > > With that in mind, we have checked not only the sentences highlighted in this > question but also other similar sentences in the whole document. We propose > the updates below listed in order of appearance throughout the document. > > > **Section 7** > > OLD: > The 'full_set' parameter MUST be included and specifies a CBOR array > 'full_set_value'. > > NEW: > The 'full_set' parameter MUST be included and MUST encode a CBOR array > 'full_set_value'. > > > **Section 8** > > OLD: > The 'diff_set' parameter MUST be present and specifies a CBOR array > 'diff_set_value' of U elements. > > NEW: > The 'diff_set' parameter MUST be present and MUST encode a CBOR array > diff_set_value' of U elements. > > > **Section 9.1** > > OLD: > The 'cursor' parameter MUST specify the CBOR simple value null (0xf6) in case > ... > > NEW: > The 'cursor' parameter MUST encode the CBOR simple value null (0xf6) in case > ... > > > **Section 9.1** > > OLD: > ... Otherwise, the 'cursor' parameter MUST specify a CBOR unsigned integer. > > NEW: > ... Otherwise, the 'cursor' parameter MUST encode a CBOR unsigned integer. > > > **Section 9.2.1** > > OLD: > The 'diff_set' parameter MUST be included and specifies the empty CBOR array. > > NEW: > The 'diff_set' parameter MUST be included and MUST encode the empty CBOR > array. > > > **Section 9.2.1** > > OLD: > The 'cursor' parameter MUST be included and specifies the CBOR simple value > null (0xf6). > > NEW: > The 'cursor' parameter MUST be included and MUST encode the CBOR simple value > null (0xf6). > > > **Section 9.2.1** > > OLD: > The 'more' parameter MUST be included and specifies the CBOR simple value > false (0xf4). > > NEW: > The 'more' parameter MUST be included and MUST encode the CBOR simple value > false (0xf4). > > > **Section 9.2.2** > > OLD: > The 'more' parameter MUST be present and MUST specify the CBOR simple value > false (0xf4) if U <= MAX_DIFF_BATCH or the CBOR simple value true (0xf5) > otherwise. > > NEW: > The 'more' parameter MUST be present. The parameter MUST encode the CBOR > simple value false (0xf4) if U <= MAX_DIFF_BATCH; otherwise, it MUST encode > the CBOR simple value true (0xf5). > > > **Section 9.2.2** > > OLD: > The 'cursor' parameter MUST be present and specifies a CBOR unsigned integer. > > NEW: > The 'cursor' parameter MUST be present and MUST encode a CBOR unsigned > integer. > > As a side note, the sentence following the quoted text says: > > OLD: > This MUST take the 'index' value ... > > Consistently with the response to question 20, that sentence can be rephrased > as follows: > > NEW: > The unsigned integer MUST take the 'index' value ... > > > **Section 9.2.2** > > OLD: > The 'more' parameter MUST be present and MUST specify the CBOR simple value > false (0xf4) if SUB_U <= MAX_DIFF_BATCH, or the CBOR simple value true (0xf5) > otherwise. > > NEW: > The 'more' parameter MUST be present. The parameter MUST encode the CBOR > simple value false (0xf4) if SUB_U <= MAX_DIFF_BATCH; otherwise, it MUST > encode the CBOR simple value true (0xf5). > > > **Section 9.2.2** > > OLD: > The 'diff_set' parameter MUST be present and specifies a CBOR array > 'diff_set_value' of L elements. > > NEW: > The 'diff_set' parameter MUST be present and MUST encode a CBOR array > 'diff_set_value' of L elements. > > > **Section 9.2.3** > > OLD: > The 'cursor' parameter MUST be present and MUST specify a CBOR unsigned > integer. In particular: ... > > NEW: > The 'cursor' parameter MUST be present and MUST encode a CBOR unsigned > integer. In particular: ... > > > **Section 9.2.3** > > OLD: > The 'more' parameter MUST be present and MUST specify the CBOR simple value > false (0xf4) if ... > > NEW: > The 'more' parameter MUST be present and MUST encode the CBOR simple value > false (0xf4) if ... > > > **Section 9.2.3** > > OLD: > The 'diff_set' parameter MUST be included and specifies the empty CBOR array. > > NEW: > The 'diff_set' parameter MUST be included and MUST encode the empty CBOR > array. > > > **Section 9.2.3** > > OLD: > The 'cursor' parameter MUST be included and specifies the CBOR simple value > null (0xf6). > > NEW: > The 'cursor' parameter MUST be included and MUST encode the CBOR simple value > null (0xf6). > > **Section 9.2.3** > > OLD: > The 'more' parameter MUST be included and specifies the CBOR simple value > true (0xf5). > > NEW: > The 'more' parameter MUST be included and MUST encode the CBOR simple value > true (0xf5). > > > **Section 9.2.3** > > OLD: > The 'diff_set' parameter MUST be present and specifies a CBOR array > 'diff_set_value' of L elements. > > NEW: > The 'diff_set' parameter MUST be present and MUST encode a CBOR array > 'diff_set_value' of L elements. > > <== > >> >> >> 22) <!--[rfced] We have attempted to break up and reorder this long >> sentence. Please review if the following suggested edit >> correctly captures your intent. >> >> Original: >> In order to further limit such a risk, when receiving an access token >> that specifies the 'exi' claim and for which a corresponding token >> hash is not stored, the RS can introspect the access token (see >> Section 5.9 of [RFC9200]), if token introspection is implemented by >> both the RS and the AS. >> >> Perhaps: >> This risk can be further limited. Specifically, if token >> introspection is implemented by both the RS and the AS, the RS can >> introspect the access token (see Section 5.9 of [RFC9200]) when >> receiving an access token that specifies the 'exi' claim and for which >> a corresponding token hash is not stored. >> >> --> >> > > ==>MT > > The suggested new phrasing is good. > > <== > >> >> >> 23) <!-- [rfced] [SHA-256] The reference to NIST FIPS 180-3 was very >> outdated. FIPS 180-3 was superseded by FIPS 180-4 in 2012. The >> latest version of this standard was released in August 2015. We >> have updated to the most recent version. Please let us know any >> objections--> >> > > ==>MT > > Thanks, that's good. > > <== > >> >> >> 24) <!--[rfced] We noticed that Table 3 contains the only use of 'index' >> parameter. Please ensure parameter (and not value or unsigned integer) >> was intended. >> >> Original: >> Max value of each instance of the 'index' parameter >> >> --> >> > > ==>MT > > Good catch! I propose to simply rephrase as follows. > > NEW: > Max value of each instance of 'index' > > <== > >> >> >> 25) <!-- [rfced] We note that Appendices D and E were tagged "removeInRFC" >> in the XML. We have removed Appendix E (change log) but left >> Appendix D as it has citations to it in the text. Please review >> and let us know if any further updates are necessary. --> >> > > ==>MT > > The intention was to eventually remove Appendix D too, after having applied > the "Note to RFC Editor" in the last paragraph of Section 1.1. > > <== > >> >> >> 26) <!--[rfced] We had the following questions/comments related to >> abbreviation use throughout the document. >> >> a) After first use with expansion, we will update the following to use >> only the abbreviation thereafter unless we hear objection: >> >> RS >> AS >> CWT >> > > ==>MT > > That looks good. > > <== > >> >> b) We have expanded the following abbreviations on first use. Please >> review and let us know any objections. >> >> IoT >> CDDL >> CBOR >> JWE >> JWS >> OSCORE >> --> >> > > ==>MT > > That looks good. > > <== > >> >> >> 27) <!--[rfced] We had the following questions regarding terminology used >> throughout the document: >> >> a) Please review the way parameter names are marked with regard to >> quotation, wo >> rd order, and the use of simply "parameter" or "query parameter". For >> example ( >> there may be more/others), we see: >> >> the 'access_token' parameter / the parameter 'access_token' >> > > ==>MT > > Please consistently use "the 'access_token' parameter" > > <== > >> >> the 'diff' query parameter / the query parameter 'diff' >> > > ==>MT > > Please consistently use "the 'diff' query parameter" > > <== > >> >> the 'cursor' query parameter / the query parameter 'cursor' / the 'cursor' >> parameter >> > > ==>MT > > Please consistently use "the 'cursor' query parameter" also instead of the > three occurrences of "the query parameter 'cursor'" of Appendices C.4 and C.5. > > Also, "the 'cursor' parameter" should be changed to "the 'cursor' query > parameter" in the following occurrences: > > * Section 6.3: "... irrespective of the presence of the 'cursor' parameter > and ..." > > * Section 6.3: "... irrespective of the value of the 'cursor' parameter and > ..." > > All the other occurrences of "the 'cursor' parameter" are correct as-is, > since they refer to the 'cursor' parameter within the payload of a response > message (which is not the same as a query parameter within the query string > of a GET request). This should already be clear enough from the context, > since those occurrences are used when describing how to compose/process such > a response payload. > > <== > >> >> Please let us know if/how these may be made uniform throughout. >> >> b) We note that most field names were in single quotes. We have updated the >> wor >> d order in some places to appear as follows: >> >> 'name' field >> > > ==>MT > > That looks good. > > <== > >> >> We also see a few uses of "unprotected" field. Is this a name? Or is >> this a different use of quotes? If a name, we suggest matching the >> pattern above. If a different concept, perhaps we can remove the >> quotes? >> > > ==>MT > > Please keep "unprotected" in double quotes. That is consistent with the use > in RFC 9052 from which the concept is taken. > > <== > >> >> >> c) We note that we normally see "a 2.05 (Content) response However, >> there is one use of "the CoAP response code 2.05 (Content). Please >> review and let us know if/how these should be made uniform. >> > > ==>MT > > It's good to make it uniform. Please update that sentence in Section 11 as > follows. > > OLD: > with a response specifying the CoAP response code 2.05 (Content). > > NEW: > with a 2.05 (Content) response. > > <== > >> >> d) Please review uses of "Cursor". When double quoted, should it always be >> foll >> owed by the word extension? Note also that [I-D.bormann-t2trg-stp] uses >> 'cursor >> ' pattern (single quotes) instead. >> >> Examples below: >> >> Originals: >> ...as specified in Section 9 in fact relies on the "Cursor" pattern of >> the Series Transfer Pattern ... >> >> If supporting "Cursor", then UB = MAX_INDEX+1 >> >> ...in a diff query response when using "Cursor" >> >> >> C.4. Diff Query with Observe and "Cursor" >> >> Figure 13: Interaction for diff query with Observe and "Cursor" >> >> C.5. Full Query with Observe plus Plus Diff Query with "Cursor" >> >> etc. >> > > ==>MT > > Yes, please add the word "extension" after the following occurrences of > "Cursor". > > * Table 3 (2 instances) > > OLD: > "Cursor" > > NEW: > the "Cursor" extension > > * Title of Appendix C.4 > > OLD: > Diff Query with Observe and "Cursor" > > NEW: > Diff Query with Observe and "Cursor" Extension > > * Caption of Figure 13 > > OLD: > Figure 13: Interaction for Diff Query with Observe and "Cursor" > > NEW: > Figure 13: Interaction for Diff Query with Observe and "Cursor" Extension > > * Title of Appendix C.5 > > OLD: > Full Query with Observe Plus Diff Query with "Cursor" > > NEW: > Full Query with Observe Plus Diff Query with "Cursor" Extension > > * Caption of Figure 14 > > OLD: > Figure 14: Interaction for Full Query with Observe Plus Diff Query with > "Cursor" > > NEW: > Figure 14: Interaction for Full Query with Observe Plus Diff Query with > "Cursor" Extension > > > As to "Cursor" pattern in Appendix A, [I-D.bormann-t2trg-stp] actually uses > "cursor" in double quotes, although all lowercase. Consistently, we can have > the following fix in Appendix A: > > OLD: > relies on the "Cursor" pattern of the STP > > NEW: > relies on the "cursor" pattern of the STP > > <== > >> >> e) Will it be clear to the reader what the difference between "hashes" >> and "HASHES" is? Please review these uses and let us know if/how we >> may update (perhaps including a citation)? Should this actually be "a >> HASHES se >> t" or "a set of >> HASHES"? >> >> Uses of HASHES: >> >> 1. From the TRL, the AS builds a set HASHES such that: >> >> * If the requester is a registered device, HASHES specifies the >> token hashes currently in the TRL and associated with the >> access tokens pertaining to that registered device. >> > > ==>MT > > All the uses of "token hashes" and "HASHES" are correct and as intended. > "token hashes" are binary values computed by means of a hash function. > "HASHES" is used only in Section 7, and it is just used as a convenient name > for a particular set of specific token hashes. > > <== > >> >> f) Please note that we have made several updates related to the use of >> the word "occur" throughout the document. Please review these and let >> us know any objections. >> > > ==>MT > > I propose the following amendments to the latest edited version. The result > would be consistent with the wording used, e.g., in Section 2 of the latest > edited version. > > * Section 1.1 > > OLD: > each related to one update to the TRL > > NEW: > each related to one update that occurred to the TRL > > * Section 2 > > OLD: > most recent updates to the whole > > NEW: > most recent updates that occurred to the whole > > * Section 6 > > OLD: > is related to one update to the TRL > > NEW: > is related to one update that occurred to the TRL > > * Section 11 > > OLD: > miss updates to its associated > > NEW: > miss updates that have occurred to its associated > > <== > >> >> g) This document uses both GET request and GET (Observation) request. >> Please review and let us know if any updates for consistency are >> necessary. >> > > ==>MT > > There is a single instance of "GET (Observation)". I think that it is fine to > simplify that sentence as follows. > > OLD: > ... additional GET (Observation) requests ... > > NEW: > ... additional GET requests ... > > <== > >> >> h) Please review the use of "Plus" in section and figure titles and >> let us know if "and" or something else is desirable. >> > > ==>MT > > I think it is fine to do the following changes using "and" instead of "plus": > > * Title of Appendix C.3 > > OLD: > C.3. Full Query with Observe Plus Diff Query > > NEW: > C.3. Full Query with Observe and Diff Query > > > * Caption of Figure 12 > > OLD: > Figure 12: Interaction for Full Query with Observe Plus Diff Query > > NEW: > Figure 12: Interaction for Full Query with Observe and Diff Query > > > * Title of Appendix C.5 > > OLD: > C.5. Full Query with Observe Plus Diff Query with "Cursor" > > NEW: > C.5. Full Query with Observe and Diff Query with "Cursor" > > > * Caption of Figure 14 > > OLD: > Figure 14: Interaction for Full Query with Observe Plus Diff Query with > "Cursor" > > NEW: > Figure 14: Interaction for Full Query with Observe and Diff Query with > "Cursor" > > <== > >> >> i) Please review the use of HASH_INPUT and Hash Input to ensure >> satisfaction with the variance. >> >> --> >> > > ==>MT > > I believe that the current use is appropriate and correct. > > There is only one occurrence of "hash input", in the title of Section 4.2, as > a short version of the plain "input for computing the token hash" used in the > second paragraph. > > HASH_INPUT is used for conveniently naming an exact value built as defined in > Section 4.2 and used as hash input. > > <== > >> >> >> 28) <!--[rfced] Please consider if it would be helpful for the reader if >> mentions of "step #" were links to the steps in the html version. >> We believe the majority of the instances were pointing to steps >> directly above or below the text in which the pointer existed; >> thus, we have not made any such update (nor do we require it). >> >> An example of how to add this functionality if you so desire: >> >> <ol type="Step %d."> >> <li>... >> <li anchor="step2">... >> <li>... >> </ol> >> >> Following is a list of all such mentions in the current text for your >> convenienc >> e: >> >> discard the access token yet; instead, it moves to step 4. >> The RS skips step 3 only if it is certain that all its pertaining >> step 3. >> The RS skips step 4 only if it is certain that all its pertaining >> step 4. >> AS moves to step 2. >> considered at step 1. >> step 3. >> because SIZE is equal to 0 at step 2), then no diff entries are >> * At step 3, the AS considers the value MAX_DIFF_BATCH (see >> * At step 4, the CBOR map to carry in the payload of the 2.05 >> update collection for that requester (see step 5 at >> * At step 3, the AS considers the value MAX_DIFF_BATCH (see >> * At step 4, the CBOR map to carry in the payload of the >> --> >> > > ==>MT > > The above is right. There are only 5 mentioned steps that are not described > nearby, and those are all beside a reference to the Section 6.2 or 8 where > the step is described. I do not think that we need to include a hyperlink to > the actual steps in question. > > <== > >> >> >> 29) <!-- [rfced] We updated artwork tags to instead be sourcecode tags in >> the XML formatting of Sections 3, 4.2.1, 4.2.2, 6.1, 7, and >> 8. Please confirm that this is correct. >> >> In addition, please consider whether the "type" attribute of any >> sourcecode element should be set and/or has been set correctly. >> >> The current list of preferred values for "type" is available at >> >> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frpc%2Fwiki%2Fdoku.php%3Fid%3Dsourcecode-types&data=05%7C02%7Cmarco.tiloca%40ri.se%7C10670f445e4a4d98ba0a08dd7bc32c79%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638802800666330557%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=j1reiaCt2Gf2sJrfLyf6BYmEh06WAdMWyOAUQpxYCzA%3D&reserved=0> >> . >> If the current list does not contain an applicable type, feel free to >> suggest additions for consideration. Note that it is also acceptable >> to leave the "type" attribute not set. >> --> >> > > ==>MT > > I suggest the value of the "type" attribute for a number of artwork tags. I > think that all the other artwork tags are fine as-is (i.e., even with the > "type" attribute not set). > > * Section 3, Figure 2 > > The "type" attribute can have value "cbor-diag" > > * Section 6.1, artwork right below "The CDDL notation ..." > > The "type" attribute can have value "cddl" > > * Section 7, Figure 6 > > The "type" attribute can have value "cddl" > > * Section 8, Figure 8 > > The "type" attribute can have value "cddl" > > <== > >> >> >> 30) <!--[rfced] Please review artwork to ensure that it fits within the >> 72-character line length limit. --> >> > > ==>MT > > All the artworks are within the 72-character line length limit. > > <== > >> >> >> 31) <!-- [rfced] 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 the quotation marks have been removed. >> >> Please review carefully and let us know if the output is acceptable or >> if any updates are needed. >> >> --> >> > > ==>MT > > The output in all formats is acceptable and correct. > > <== > >> >> >> 32) <!--[rfced] Please review cases such as the following knowing that we >> can us >> e <sub> or <sup> to express mathematical meaning (see >> >> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthors.ietf.org%2Frfcxml-vocabulary%23sup&data=05%7C02%7Cmarco.tiloca%40ri.se%7C10670f445e4a4d98ba0a08dd7bc32c79%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638802800666347662%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=DoAEJJlnOH3lOGobhsNkSlQLhkXFgvqWQcnFiSLWe7g%3D&reserved=0 >> ) and let us know if/how we should >> update: >> >> Original: >> >> The AS defines the single, constant unsigned integer MAX_INDEX <= >> ((2^64) - 1), where "^" is the exponentiation operator. --> >> > > ==>MT > > "<sup>...</sup>" can be used in the following cases. > > * Section 6.2.1 > > (2^64) > > * Section 6.2.1 > > (2^32) > > * Appendix B, Table 3, Column "Values" > > (2^64) > > > Consequently, the following rephrasing also applies. > > * Section 6.2.1 > > OLD: > , where "^" is the exponentiation operator. The value > > NEW: > . The value > > * Appendix B: > > OLD: > bound, respectively, and "^" is the exponentiation operator. > > NEW: > bound, respectively. > > <== > >> >> >> 33) <!-- [rfced] Please review the "Inclusive Language" portion of the >> online Style Guide >> >> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02%7Cmarco.tiloca%40ri.se%7C10670f445e4a4d98ba0a08dd7bc32c79%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638802800666363385%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4u2JnjcwZ%2Bb61kX%2BO0BjQhgKcgdl0iA9YJkZqhdwdQ4%3D&reserved=0> >> >> 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. >> >> --> >> > > ==>MT > > I could not find anything to change. > > <== > >> >> >> Thank you. >> >> RFC Editor/mf >> >> *****IMPORTANT***** >> >> Updated 2025/04/14 >> >> 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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ffaq%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7C10670f445e4a4d98ba0a08dd7bc32c79%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638802800666379514%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MZsaj%2FJDG%2B%2Bbyz13Lez2nQkx1wL4yARCI2w7K4i1q6c%3D&reserved=0 >> ). >> >> 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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustee.ietf.org%2Flicense-info&data=05%7C02%7Cmarco.tiloca%40ri.se%7C10670f445e4a4d98ba0a08dd7bc32c79%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638802800666393138%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=5ROtKB0%2BkXe07ZxxA0zsf6Wb%2Fxmv94wmfcQc5pksRzU%3D&reserved=0 >> ). >> >> * 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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthors.ietf.org%2Frfcxml-vocabulary&data=05%7C02%7Cmarco.tiloca%40ri.se%7C10670f445e4a4d98ba0a08dd7bc32c79%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638802800666406231%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=dg4TvPJKJfqv%2FpzKLJkFGFgHcf2ZWQ86iQCkoDXRfHk%3D&reserved=0> >> . >> >> * 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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIAe6P8O4Zc&data=05%7C02%7Cmarco.tiloca%40ri.se%7C10670f445e4a4d98ba0a08dd7bc32c79%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638802800666422569%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Nbx3z531DZX1vHdy1zFUG05nNKLEJaLPNHdBxhKcFfA%3D&reserved=0 >> >> >> * The archive itself: >> >> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7C10670f445e4a4d98ba0a08dd7bc32c79%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638802800666438441%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ru%2FNRPHbmVQqCHNdID6f1q%2FOqZk3ioNdwCvH%2BuyveWM%3D&reserved=0 >> >> >> * 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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9770.xml&data=05%7C02%7Cmarco.tiloca%40ri.se%7C10670f445e4a4d98ba0a08dd7bc32c79%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638802800666453936%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Q3fSMMDvH8LWUbZ0v%2BzltUC2mRHM%2BmfIOabSD9fjops%3D&reserved=0 >> >> >> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9770.html&data=05%7C02%7Cmarco.tiloca%40ri.se%7C10670f445e4a4d98ba0a08dd7bc32c79%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638802800666469345%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=wiP0ArBwO7loobQFZ%2Fwll88hY%2BJ%2B930cfWGzUkoXQiQ%3D&reserved=0 >> >> >> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9770.pdf&data=05%7C02%7Cmarco.tiloca%40ri.se%7C10670f445e4a4d98ba0a08dd7bc32c79%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638802800666484942%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=uZuwvCn3SDNwB7dGyZrB%2FGeMTCn5bvZW5%2FbsvXMywaM%3D&reserved=0 >> >> >> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9770.txt&data=05%7C02%7Cmarco.tiloca%40ri.se%7C10670f445e4a4d98ba0a08dd7bc32c79%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638802800666500341%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=SqKSn34g7UFFDAZTePSewCkmj1Hu0vPWKBLLbIiAYyo%3D&reserved=0 >> >> >> Diff file of the text: >> >> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9770-diff.html&data=05%7C02%7Cmarco.tiloca%40ri.se%7C10670f445e4a4d98ba0a08dd7bc32c79%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638802800666515633%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=v4xJTRwzV8%2ByL9ADFp%2FUiIskOFGjTRnd0tU%2FiynCd3o%3D&reserved=0 >> >> >> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9770-rfcdiff.html&data=05%7C02%7Cmarco.tiloca%40ri.se%7C10670f445e4a4d98ba0a08dd7bc32c79%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638802800666531276%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=oogcUANwaA%2FrCCTwPtZMac4xrmpF4%2BHwbiuXy87rPhA%3D&reserved=0 >> (side by side) >> >> Diff of the XML: >> >> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9770-xmldiff1.html&data=05%7C02%7Cmarco.tiloca%40ri.se%7C10670f445e4a4d98ba0a08dd7bc32c79%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638802800666547048%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ApM%2FvyXorMVW%2FrmhDjd1yrwP7y610dnfO4YK5eLkNyA%3D&reserved=0 >> >> >> >> Tracking progress >> ----------------- >> >> The details of the AUTH48 status of your document are here: >> >> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9770&data=05%7C02%7Cmarco.tiloca%40ri.se%7C10670f445e4a4d98ba0a08dd7bc32c79%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638802800666564582%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rl5kDCHNhx1lRCjF4gL9%2BBeK2HlrwIgQfig5r8OX9Wg%3D&reserved=0 >> >> >> Please let us know if you have any questions. >> >> Thank you for your cooperation, >> >> RFC Editor >> >> -------------------------------------- >> RFC9770 (draft-ietf-ace-revoked-token-notification-09) >> >> Title : Notification of Revoked Access Tokens in the >> Authentication and Authorization for Constrained Environments (ACE) Framework >> Author(s) : M. Tiloca, F. Palombini, S. Echeverria, G. Lewis >> WG Chair(s) : Loganaden Velvindron, Tim Hollebeek >> >> Area Director(s) : Deb Cooley, Paul Wouters >> >> >> > > -- > Marco Tiloca > Ph.D., Senior Researcher > > Phone: +46 (0)70 60 46 501 > > RISE Research Institutes of Sweden AB > Box 1263 > 164 29 Kista (Sweden) > > Division: Digital Systems > Department: Computer Science > Unit: Cybersecurity > > > https://www.ri.se > <OpenPGP_0xEE2664B40E58DA43.asc> -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
