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
