Hi Paul, Thanks for getting back to us on this issue.
We’ve noted your comments at the AUTH48 status page (http://www.rfc-editor.org/auth48/rfc9770) and look forward to discussing with the authors. RFC Editor/mf > On Apr 24, 2025, at 12:17 PM, Paul Wouters <paul.wout...@aiven.io> wrote: > > > On Tue, Apr 22, 2025 at 12:49 PM Megan Ferguson > <mfergu...@staff.rfc-editor.org> wrote: > Greetings, > > Just a friendly weekly reminder that this document awaits your attention. > Please see the document-specific questions > and AUTH48 announcement in this thread and let us know if we can be of > assistance as you begin the AUTH48 review process. > > Please note that the AUTH48 status page of this document is viewable at: > > http://www.rfc-editor.org/auth48/rfc9770 > > AUTH48 FAQs are available at: https://www.rfc-editor.org/faq/#auth48 > > We look forward to hearing from you at your earliest convenience. > > Thank you. > > RFC Editor/mf > > > On Apr 14, 2025, at 8:12 PM, rfc-edi...@rfc-editor.org wrote: > > > > Authors and *AD, > > > > [AD - please review and weigh in on Question 21.] > > I agree that your proposed new text is clearer and approve of the change, > provided the authors have no issues with it. > > Paul > > > > > > 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] 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). > > > > --> > > > > > > 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 > > ]... > > > > --> > > > > > > 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. > > > > --> > > > > > > 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." > > > > --> > > > > > > 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. > > --> > > > > > > 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. > > > > --> > > > > > > 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). > > > > --> > > > > > > 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]). > > --> > > > > > > 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. > > > > --> > > > > > > 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. > > --> > > > > > > 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.--> > > > > > > 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). > > --> > > > > > > 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}. > > --> > > > > > > 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. > > --> > > > > > > 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. > > > > --> > > > > > > 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. > > > > > > --> > > > > > > 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). > > > > --> > > > > > > 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. > > > > --> > > > > > > 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. > > > > --> > > > > > > 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). > > > > > > --> > > > > > > 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. > > > > --> > > > > > > 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--> > > > > > > 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 > > > > --> > > > > > > 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. --> > > > > > > 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 > > > > b) We have expanded the following abbreviations on first use. Please > > review and let us know any objections. > > > > IoT > > CDDL > > CBOR > > JWE > > JWS > > OSCORE > > --> > > > > > > 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' > > > > the 'diff' query parameter / the query parameter 'diff' > > > > the 'cursor' query parameter / the query parameter 'cursor' / the 'cursor' > > parameter > > > > 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 > > > > 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? > > > > > > 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. > > > > 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. > > > > 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. > > > > 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. > > > > g) This document uses both GET request and GET (Observation) request. > > Please review and let us know if any updates for consistency are > > necessary. > > > > h) Please review the use of "Plus" in section and figure titles and > > let us know if "and" or something else is desirable. > > > > i) Please review the use of HASH_INPUT and Hash Input to ensure > > satisfaction with the variance. > > > > --> > > > > > > 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 > > --> > > > > > > 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://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. > > 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. > > --> > > > > > > 30) <!--[rfced] Please review artwork to ensure that it fits 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. > > > > --> > > > > > > 32) <!--[rfced] Please review cases such as the following knowing that we > > can us > > e <sub> or <sup> to express mathematical meaning (see > > https://authors.ietf.org/rfcxml-vocabulary#sup) 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. --> > > > > > > 33) <!-- [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. > > > > --> > > > > > > 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://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/rfc9770.xml > > https://www.rfc-editor.org/authors/rfc9770.html > > https://www.rfc-editor.org/authors/rfc9770.pdf > > https://www.rfc-editor.org/authors/rfc9770.txt > > > > Diff file of the text: > > https://www.rfc-editor.org/authors/rfc9770-diff.html > > https://www.rfc-editor.org/authors/rfc9770-rfcdiff.html (side by side) > > > > Diff of the XML: > > https://www.rfc-editor.org/authors/rfc9770-xmldiff1.html > > > > > > Tracking progress > > ----------------- > > > > The details of the AUTH48 status of your document are here: > > https://www.rfc-editor.org/auth48/rfc9770 > > > > 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 > > > > > > > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
