I've reviewed the document, and it looks fine. It's approved for publication.
> On Jul 8, 2025, at 10:08 AM, Kaelin Foody <kfo...@staff.rfc-editor.org> wrote:
>
> Hi Alan,
>
> This is a friendly reminder that we await your approval regarding this
> document’s readiness for publication. Please see our previous message to
> review the updated files, and let us know if you have any further updates or
> if you approve this document in its current form.
>
> Thank you,
> RFC Editor/kf
>
>> On Jun 20, 2025, at 5:27 PM, Kaelin Foody <kfo...@staff.rfc-editor.org>
>> wrote:
>>
>> Hi Alan,
>>
>> Thanks for your reply. We have updated our files accordingly.
>>
>> Per your reply we have not expanded the abbreviations below:
>>
>>>> c) Per Section 3.6 of RFC 7322 ("RFC Style Guide"), abbreviations should be
>>>> expanded upon first use. How should "PSK-DH" and "ECDHE_PSK" be expanded
>>>> below?
>>>
>>> Those terms are related to TLS, and are more "fixed names" than
>>> abbreviations.
>>>
>>> PSK-DH is used in RFC9257 without expansion or definition. ECDHE_PSK is
>>> used in RFC5489 without expansion or definition.
>>>
>>> On quick search, I can't find an RFC where those terms are defined.
>>>
>>> I'm not objecting to the proposed text, but I'm not sure we want to define
>>> the terms here, when the referenced RFC doesn't define the terms.
>>
>>
>> The updated files have been posted here (please refresh):
>> https://www.rfc-editor.org/authors/rfc9813.txt
>> https://www.rfc-editor.org/authors/rfc9813.pdf
>> https://www.rfc-editor.org/authors/rfc9813.html
>> https://www.rfc-editor.org/authors/rfc9813.xml
>>
>> The relevant diff files have been posted here (please refresh):
>> https://www.rfc-editor.org/authors/rfc9813-diff.html (comprehensive diff)
>> https://www.rfc-editor.org/authors/rfc9813-rfcdiff.html (side by side)
>> https://www.rfc-editor.org/authors/rfc9813-auth48diff.html (AUTH48 changes
>> only)
>>
>> Please review and let us know any further updates you may have or if you
>> approve this document in its current form.
>>
>> Thank you,
>> RFC Editor/kf
>>
>> On Jun 18, 2025, at 9:39 AM, Alan DeKok
>> <alan.dekok=40inkbridge...@dmarc.ietf.org> wrote:
>>>
>>> On Jun 17, 2025, at 1:49 PM, rfc-edi...@rfc-editor.org wrote:
>>>> 1) <!-- [rfced] The title of the document has been updated as follows.
>>>> "TLS-PSK" has been expanded as "TLS Pre-Shared Key"; however, please
>>>> let us know if it should be expanded otherwise both here and in the rest
>>>> of the document.
>>>>
>>>> Original:
>>>> Operational Considerations for RADIUS and TLS-PSK
>>>>
>>>> Option A (current title):
>>>> Operational Considerations for RADIUS and TLS Pre-Shared Key (TLS-PSK)
>>>>
>>>> Option B (using the phrase from the abstract):
>>>> Operational Considerations for Using TLS Pre-Shared Keys (TLS-PSKs) with
>>>> RADIUS
>>>>
>>>> Option C (more similar to the title of RFC 4279):
>>>> Operational Considerations for RADIUS and TLS Pre-Shared Key (TLS-PSK)
>>>> Cipher Suites
>>>>
>>>> [Note: RFC 4279 has been cited for "TLS-PSK" in RFCs 6614, 6940, and 7593.]
>>>> -->
>>>
>>> Option B seems best
>>>
>>>>
>>>> 2) <!--[rfced] This document has been assigned a new BCP number. Please
>>>> let us know
>>>> if this is not correct (i.e., it should be part of an existing BCP).
>>>>
>>>> See the complete list of BCPs here: https://www.rfc-editor.org/bcps
>>>> -->
>>>
>>> A new BCP is fine. We will likely be adding more RADIUS BCP specificatons
>>> in the future. Perhaps they could all be put under a common "RADIUS
>>> Operational Considerations" BCP?
>>>
>>>> 3) <!-- [rfced] Please insert any keywords (beyond those that appear in
>>>> the title) for use on https://www.rfc-editor.org/search. -->
>>>>
>>>>
>>>> 4) <!-- [rfced] What specific text does "base32 in the example below"
>>>> refer to?
>>>> May we update to provide a more clear pointer for the reader?
>>>
>>> It refers to the later sample commands:
>>>
>>> dd if=/dev/urandom bs=1 count=16 | base32
>>>
>>> Adding a clear pointer would help.
>>>
>>>> 5) <!-- [rfced] Section 4.2: We have made some updates to the numbered
>>>> list
>>>> at the end of this section, in order to make the list items more
>>>> parallel. Please review and let us know any further updates. -->
>>>
>>> The changes are fine.
>>>
>>>> 6) <!-- [rfced] For readability, may we format this sentence as a list?
>>>>
>>>> Original:
>>>> For example, the identity may have incorrect UTF-8 format; or it may
>>>> contain data which forms an injection attack for SQL, LDAP, REST or shell
>>>> meta characters; or it may contain embedded NUL octets which are
>>>> incompatible with APIs which expect NUL terminated strings.
>>>>
>>>> Perhaps:
>>>> For example, the identity may:
>>>>
>>>> * have an incorrect UTF-8 format,
>>>>
>>>> * contain data that forms an injection attack for SQL, the Lightweight
>>>> Directory Access Protocol (LDAP), Representational State Transfer
>>>> (REST), or shell meta characters, or
>>>>
>>>> * contain embedded NUL octets that are incompatible with APIs that
>>>> expect NUL terminated strings.
>>>> -->
>>>
>>> Yes, that's fine.
>>>
>>>>
>>>> 7) <!-- [rfced] For clarity, may we update the second part of this
>>>> sentence
>>>> to repeat "expose"? This helps to avoid misreading "fields" as a verb.
>>>>
>>>> Original:
>>>> The client implementation can then expose a user interface flag which is
>>>> "TLS yes / no", and then also fields which ask for the PSK Identity and PSK
>>>> itself.
>>>>
>>>> Perhaps:
>>>> The client implementation can then expose a user interface flag that is
>>>> "TLS yes / no", and also expose fields that ask for the PSK Identity and
>>>> PSK
>>>> itself.
>>>> -->
>>>
>>> The proposal is good, but change "expose" to "provide", which is a little
>>> more neutral.
>>>
>>>> 8) <!-- [rfced] Regarding this text in Section 5:
>>>> a) May we update the first sentence to avoid repetition of "TLS 1.3"?
>>>> b) This exact text appears again in Section 6 (i.e., for clients
>>>> and servers). Please review and confirm it is correct for this text
>>>> to appear twice in this document.
>>>
>>> The proposed text is fine. It's OK for the text to appear twice.
>>>
>>>> 9) <!-- [rfced] Is "clients" meant to be singular possessive or
>>>> plural possessive in the text below?
>>>
>>> singular possesive.
>>>
>>>> 10) <!-- [rfced] Informative reference RFC 5077 has been obsoleted by
>>>> RFC 8446. We recommend replacing RFC 5077 with RFC 8446. However, if RFC
>>>> 5077 must be referenced, we suggest mentioning RFC 8446 (e.g., "RFC 5077
>>>> has
>>>> been obsoleted by RFC 8446.") See Section 4.8.6 in the RFC Style Guide
>>>>
>>>> (RFC 7322). -->
>>>
>>> We can change the reference from RFC 5077 Section 4, to RFC8446, Section
>>> 4.6.1
>>>
>>>>
>>>> 11) <!-- [rfced] Abbreviations and Terminology:
>>>>
>>>> a) We note "pre-shared key" appears frequently after the abbreviation "PSK"
>>>> is introduced. May we update instances of "pre-shared key" to its
>>>> abbreviation
>>>> after it is first expanded?
>>>
>>> Yes.
>>>
>>>> b) FYI, we changed "PKSs" to "PSKs" in the text below. Please review
>>>> whether this is correct.
>>>
>>> It's correct.
>>>
>>>
>>>
>>>> c) Per Section 3.6 of RFC 7322 ("RFC Style Guide"), abbreviations should be
>>>> expanded upon first use. How should "PSK-DH" and "ECDHE_PSK" be expanded
>>>> below?
>>>
>>> Those terms are related to TLS, and are more "fixed names" than
>>> abbreviations.
>>>
>>> PSK-DH is used in RFC9257 without expansion or definition. ECDHE_PSK is
>>> used in RFC5489 without expansion or definition.
>>>
>>> On quick search, I can't find an RFC where those terms are defined.
>>>
>>> I'm not objecting to the proposed text, but I'm not sure we want to define
>>> the terms here, when the referenced RFC doesn't define the terms.
>>>
>>>> d) FYI, we added expansions upon first use for the abbreviations below.
>>>> Please
>>>> review each expansion in the document carefully to ensure correctness.
>>>>
>>>> Lightweight Directory Access Protocol (LDAP)
>>>> Representational State Transfer (REST)
>>>> Network Access Server (NAS)
>>>> -->
>>>
>>> Yes, that's fine.
>>>
>>>>
>>>> 12) <!-- [rfced] FYI, we fixed the links to the sections as follows.
>>>> Please review to ensure these updates are correct.
>>>>
>>>> Original:
>>>> Further discussion of this topic is contained in []{#sharing}.
>>>>
>>>> See {}(#resumption) below for more discussion of issues around resumption.
>>>>
>>>> Current:
>>>> Further discussion of this topic is contained in Section 4.3.
>>>>
>>>> See Section 6.2.3 below for more discussion of issues around resumption.
>>>> -->
>>>
>>> That's fine.
>>>
>>>>
>>>> 13) <!-- [rfced] We updated artwork to sourcecode in Section 4.1.2. Please
>>>> confirm
>>>> that this is correct.
>>>
>>> That's fine.
>>>
>>>> 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.
>>>> -->
>>>
>>> The "type" here should be "shell"
>>>
>>> Alan DeKok.
>>>
>>
>
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
