Re: [auth48] AUTH48: RFC-to-be 9310 <draft-ietf-lamps-5g-nftypes-08> for your review

[Lynne Bartholomew <[e-mail]>]

Hi, Daniel.  No worries!  We have noted your approval:

  https://www.rfc-editor.org/auth48/rfc9310

As we now have all approvals, we will prepare this document for publication shortly.

Thank you!

RFC Editor/lb

> On Jan 9, 2023, at 12:41 PM, Daniel Migault <[e-mail]> wrote:
> 
> Please proceed to publication. Apologise for the delay
> Yours,
> Daniel
> 
> ________________________________________
> From: Lynne Bartholomew <[e-mail]>
> Sent: Monday, January 9, 2023 1:26 PM
> To: John Mattsson; Sean Turner; Russ Housley
> Cc: Roman Danyliw; Daniel Migault; [e-mail]; [e-mail]; Tim Hollebeek; [e-mail]; RFC Editor
> Subject: Re: AUTH48: RFC-to-be 9310 <draft-ietf-lamps-5g-nftypes-08> for your review
> 
> Happy New Year, John, Sean, and Russ!
> 
> John, thank you for the updated XML file.  We downloaded 3GPP TS:33.310 V17.5.0 and see that it is dated December 2022, so we used that date accordingly.
> 
> The files reflecting this latest update are posted here (please refresh your browser) *:
> 
>   https://www.rfc-editor.org/authors/rfc9310.txt
>   https://www.rfc-editor.org/authors/rfc9310.pdf
>   https://www.rfc-editor.org/authors/rfc9310.html
>   https://www.rfc-editor.org/authors/rfc9310.xml
>   https://www.rfc-editor.org/authors/rfc9310-diff.html
>   https://www.rfc-editor.org/authors/rfc9310-rfcdiff.html
>   https://www.rfc-editor.org/authors/rfc9310-auth48diff.html
>   https://www.rfc-editor.org/authors/rfc9310-lastdiff.html
>   https://www.rfc-editor.org/authors/rfc9310-lastrfcdiff.html
> 
>   https://www.rfc-editor.org/authors/rfc9310-xmldiff1.html
>   https://www.rfc-editor.org/authors/rfc9310-xmldiff2.html
> 
> * Please note that we are aware of the erroneous "RFC Publisher" entries that currently appear in the References sections; this bug has been reported.
> 
> We have noted your approvals on the AUTH48 status page:
> 
>   https://www.rfc-editor.org/auth48/rfc9310
> 
> After we receive approval from Daniel, we will move this document forward for publication.
> 
> Thanks again!
> 
> RFC Editor/lb
> 
> 
>> On Jan 9, 2023, at 6:40 AM, Russ Housley <[e-mail]> wrote:
>> 
>> Please proceed with publication.
>> 
>> Russ
> 
> 
>> On Jan 9, 2023, at 6:24 AM, Sean Turner <[e-mail]> wrote:
>> 
>> I believe this is ready for publication too.
>> 
>> spt
>> 
>>> On Jan 9, 2023, at 01:45, John Mattsson <[e-mail]> wrote:
>>> 
>>> Hi,
>>> 
>>> All the best for the new year!
>>> 
>>> Looks great and ready for publication. 3GPP published a new Release 17 version of 33.310. I have updated the reference in the attached xml-file.
>>> 
>>> Cheers,
>>> John
>>> 
>>> From: Sandy Ginoza <[e-mail]>
>>> Date: Saturday, 31 December 2022 at 22:15
>>> To: John Mattsson <[e-mail]>
>>> Cc: Russ Housley <[e-mail]>, Roman Danyliw <[e-mail]>, Daniel Migault <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Sean Turner <[e-mail]>, RFC Editor <[e-mail]>
>>> Subject: Re: AUTH48: RFC-to-be 9310 <draft-ietf-lamps-5g-nftypes-08> for your review
>>> 
>>> Hi all,
>>> 
>>> Happy New Year’s Eve!
>>> 
>>> If I understand correctly, the document should match what appears below.  The text has been updated to reflect the order of NF Types shown below - please see the updates and let us know if any other changes are needed or if you approve the RFC for publication.
>>> 
>>> The current files are available here:
>>> 
>>>  https://www.rfc-editor.org/authors/rfc9310.xml
>>>  https://www.rfc-editor.org/authors/rfc9310.txt
>>>  https://www.rfc-editor.org/authors/rfc9310.pdf
>>>  https://www.rfc-editor.org/authors/rfc9310.html
>>> 
>>> Diffs highlighting the most recent update only:
>>>  https://www.rfc-editor.org/authors/rfc9310-lastdiff.html
>>>  https://www.rfc-editor.org/authors/rfc9310-lastrfcdiff.html (side by side)
>>> 
>>> AUTH48 diff:
>>>  https://www.rfc-editor.org/authors/rfc9310-auth48diff.html
>>> 
>>> Comprehensive diffs:
>>>  https://www.rfc-editor.org/authors/rfc9310-diff.html
>>>  https://www.rfc-editor.org/authors/rfc9310-rfcdiff.html (side by side)
>>> 
>>> 
>>> Thank you,
>>> RFC Editor/sg
>>> 
>>> 
>>> 
>>>> On Dec 22, 2022, at 11:55 PM, John Mattsson <john.mattsson=[e-mail]> wrote:
>>>> 
>>>> Russ wrote:
>>>>> That matches the most recent version of Appendix B.
>>>> 
>>>> Just to be clear. Your generated table does not match
>>>> https://www.rfc-editor.org/authors/rfc9310.txt
>>>> Your table matches the most recent version of Appendix B after the ordering error that I pointed out is fixed. The document should be updated to look like your table.
>>>> 
>>>> Cheers,
>>>> John
>>>> 
>>>> From: Russ Housley <[e-mail]>
>>>> Date: Thursday, 22 December 2022 at 20:12
>>>> To: John Mattsson <[e-mail]>
>>>> Cc: Lynne Bartholomew <[e-mail]>, Sean Turner <[e-mail]>, Daniel Migault <[e-mail]>, RFC Editor <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Roman D. Danyliw <[e-mail]>, [e-mail] <[e-mail]>
>>>> Subject: Re: AUTH48: RFC-to-be 9310 <draft-ietf-lamps-5g-nftypes-08> for your review
>>>> 
>>>> John:
>>>> 
>>>> We were asked about ordering during IESG Evaluation, so I think we should keep it.
>>>> 
>>>> When I use python to sort the NF Types, I get this:
>>>> 
>>>>      "5G_DDNMF"        "LMF"             "PKMF"
>>>>      "5G_EIR"          "MBSF"            "SCEF"
>>>>      "AANF"            "MBSTF"           "SCP"
>>>>      "ADRF"            "MB_SMF"          "SCSAS"
>>>>      "AF"              "MB_UPF"          "SCSCF"
>>>>      "AMF"             "MFAF"            "SEPP"
>>>>      "AUSF"            "MME"             "SMF"
>>>>      "BSF"             "MNPF"            "SMSF"
>>>>      "CBCF"            "N3IWF"           "SMS_GMSC"
>>>>      "CEF"             "NEF"             "SMS_IWMSC"
>>>>      "CHF"             "NRF"             "SOR_AF"
>>>>      "DCCF"            "NSACF"           "SPAF"
>>>>      "DRA"             "NSSAAF"          "TSCTSF"
>>>>      "EASDF"           "NSSF"            "UCMF"
>>>>      "GBA_BSF"         "NSWOF"           "UDM"
>>>>      "GMLC"            "NWDAF"           "UDR"
>>>>      "HSS"             "PANF"            "UDSF"
>>>>      "ICSCF"           "PCF"             "UPF"
>>>>      "IMS_AS"          "PCSCF"
>>>> 
>>>> That matches the most recent version of Appendix B.
>>>> 
>>>> Russ
>>>> 
>>>> 
>>>> On Dec 22, 2022, at 1:32 AM, John Mattsson <[e-mail]> wrote:
>>>> 
>>>> Thanks Lynne,
>>>> 
>>>> In ASCII, underscore has the value 95 and comes after all capital letters. So the ascending lexicographic order of the four types starting with "MB" is:
>>>> 
>>>> "MBSF"
>>>> "MBSTF"
>>>> "MB_SMF"
>>>> "MB_UPF"
>>>> 
>>>> @Russ, @Sean, if the sorting is not strictly needed and only for human readers, an alternative could be to remove the MUST in the sentence on ordering.
>>>> 
>>>> Cheers,
>>>> John
>>>> 
>>>> From: Lynne Bartholomew <[e-mail]>
>>>> Date: Thursday, 22 December 2022 at 00:46
>>>> To: John Mattsson <[e-mail]>
>>>> Cc: Russ Housley <[e-mail]>, Sean Turner <[e-mail]>, Daniel Migault <[e-mail]>, RFC Editor <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Roman D. Danyliw <[e-mail]>, [e-mail] <[e-mail]>
>>>> Subject: Re: AUTH48: RFC-to-be 9310 <draft-ietf-lamps-5g-nftypes-08> for your review
>>>> 
>>>> Hi, John.
>>>> 
>>>> We have updated this document per your notes below.
>>>> 
>>>> The latest files are posted here:
>>>> 
>>>>  https://www.rfc-editor.org/authors/rfc9310.txt
>>>>  https://www.rfc-editor.org/authors/rfc9310.pdf
>>>>  https://www.rfc-editor.org/authors/rfc9310.html
>>>>  https://www.rfc-editor.org/authors/rfc9310.xml
>>>>  https://www.rfc-editor.org/authors/rfc9310-diff.html
>>>>  https://www.rfc-editor.org/authors/rfc9310-rfcdiff.html
>>>>  https://www.rfc-editor.org/authors/rfc9310-auth48diff.html
>>>>  https://www.rfc-editor.org/authors/rfc9310-lastdiff.html
>>>>  https://www.rfc-editor.org/authors/rfc9310-lastrfcdiff.html
>>>> 
>>>>  https://www.rfc-editor.org/authors/rfc9310-xmldiff1.html
>>>>  https://www.rfc-editor.org/authors/rfc9310-xmldiff2.html
>>>> 
>>>> We have noted your approval on the AUTH48 status page:
>>>> 
>>>>  https://www.rfc-editor.org/auth48/rfc9310
>>>> 
>>>> Thank you!
>>>> 
>>>> RFC Editor/lb
>>>> 
>>>>> On Dec 21, 2022, at 2:31 PM, John Mattsson <[e-mail]> wrote:
>>>>> 
>>>>> Hi Lynne,
>>>>> 
>>>>>> Please let us know if we should (1) change "49" to "56" in the Introduction >to reflect the latest version of [TS29.510] and (2) update the list in >Appendix A with the seven additional values.
>>>>> 
>>>>> Yes, please do change "49" to "56" and update the appendix. Release 17 is now frozen, so 56 should be the final number of NF Types in Release 17.
>>>>> 
>>>>> Cheers,
>>>>> John
>>>> 
>>>> 
>>>>> From: Lynne Bartholomew <[e-mail]>
>>>>> Date: Wednesday, 21 December 2022 at 22:47
>>>>> To: John Mattsson <[e-mail]>
>>>>> Cc: Russ Housley <[e-mail]>, Sean Turner <[e-mail]>, Daniel Migault <[e-mail]>, RFC Editor <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Roman D. Danyliw <[e-mail]>, [e-mail] <[e-mail]>
>>>>> Subject: Re: AUTH48: RFC-to-be 9310 <draft-ietf-lamps-5g-nftypes-08> for your review
>>>>> Hi, John.
>>>>> 
>>>>> While verifying the cited information in the updated 3GPP technical specifications that you listed below, we found that there are now 56 NF Types listed in Table 6.1.6.3.3-1 of [TS29.510], in contrast to the previous 49 (as noted in the Introduction:  "There are 49 NF Types defined for 3GPP Release 17; they are listed in Table 6.1.6.3.3-1 of [TS29.510]".
>>>>> 
>>>>> Please let us know if we should (1) change "49" to "56" in the Introduction to reflect the latest version of [TS29.510] and (2) update the list in Appendix A with the seven additional values.
>>>>> 
>>>>> We will wait to hear from you before proceeding.
>>>>> 
>>>>> Thank you!
>>>>> 
>>>>> RFC Editor/lb
>>>> 
>>>> 
>>>> 
>>>>> On Dec 21, 2022, at 4:44 AM, John Mattsson <[e-mail]> wrote:
>>>>> 
>>>>> Thanks Lynne,
>>>>> I approve of the document with or without changes.
>>>>> I have thoroughly reviewed the document. I have three suggested changes, see below.
>>>>> 
>>>>> 
>>>>> - "the NFTypes MUST appear in ascending sort order."
>>>>> "listed below in alphabetical order"
>>>>> The sort order in the normative sentence is not defined. As it is a normative MUST I think it needs to be exactly defined. I don't think the term alphabetic order is well-defined when some of the strings contain numerals and non-letter characters such as '_' and '-'.
>>>>> https://en.wikipedia.org/wiki/Alphabetical_order
>>>>> https://en.wikipedia.org/wiki/Lexicographic_order
>>>>> 
>>>>> Suggestion:
>>>>> 
>>>>> OLD: the NFTypes MUST appear in ascending sort order.
>>>>> NEW: the NFTypes MUST appear in ascending lexigraphic order using the ASCII values.
>>>>> 
>>>>> OLD: listed below in alphabetical order
>>>>> NEW: listed below in ascending lexigraphic order
>>>>> 
>>>>> - I think it is good to specify that it is 3GPP Release 17 in some more places (Release 18 will add at least 7 more NF Types).
>>>>> OLD: See Appendix A for values defined in 3GPP
>>>>> NEW: See Appendix A for values defined in 3GPP Release 17
>>>>> OLD: these enumeration values are listed below
>>>>> NEW: these enumeration values in 3GPP Release 17 are listed below
>>>>> - The 3GPP references should probably be to the latest published Release 17 versions.
>>>>> OLD:
>>>>>             17)", 3GPP TS:29.510 V17.5.0, March 2022,
>>>>>             <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-23a450388a88802a&q=1&e=07ebb231-8128-45b6-9f8c-6c44b3e6db50&u=https%3A%2F%2Fwww.3gpp.org%2Fftp%2FSpecs%2F
>>>>>             archive/29_series/29.510/29510-h50.zip>.
>>>>> NEW:
>>>>>             17)", 3GPP TS:29.510 V17.8.0, December 2022,
>>>>>             <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-23a450388a88802a&q=1&e=07ebb231-8128-45b6-9f8c-6c44b3e6db50&u=https%3A%2F%2Fwww.3gpp.org%2Fftp%2FSpecs%2F
>>>>>             archive/29_series/29.510/29510-h80.zip>.
>>>>> OLD:
>>>>>             (Release 17)", 3GPP TS:33.310 V17.2.0, March 2022,
>>>>>             <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-23a450388a88802a&q=1&e=07ebb231-8128-45b6-9f8c-6c44b3e6db50&u=https%3A%2F%2Fwww.3gpp.org%2Fftp%2FSpecs%2F
>>>>>             archive/33_series/33.310/33310-h20.zip>.
>>>>> NEW:
>>>>>             (Release 17)", 3GPP TS:33.310 V17.4.0, September 2022,
>>>>>             <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-23a450388a88802a&q=1&e=07ebb231-8128-45b6-9f8c-6c44b3e6db50&u=https%3A%2F%2Fwww.3gpp.org%2Fftp%2FSpecs%2F
>>>>>             archive/33_series/33.310/33310-h40.zip>.
>>>>> 
>>>>> OLD:
>>>>>             (Release 17)", 3GPP TS:29.571 V17.5.0, March 2022,
>>>>>             <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-23a450388a88802a&q=1&e=07ebb231-8128-45b6-9f8c-6c44b3e6db50&u=https%3A%2F%2Fwww.3gpp.org%2Fftp%2FSpecs%2F
>>>>>             archive/29_series/29.571/29571-h50.zip>.
>>>>> NEW:
>>>>>             (Release 17)", 3GPP TS:29.571 V17.8.0, December 2022,
>>>>>             <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-23a450388a88802a&q=1&e=07ebb231-8128-45b6-9f8c-6c44b3e6db50&u=https%3A%2F%2Fwww.3gpp.org%2Fftp%2FSpecs%2F
>>>>>             archive/29_series/29.571/29571-h80.zip>.
>>>>> Cheers,
>>>>> John
>>>>> From: Lynne Bartholomew <[e-mail]>
>>>>> Date: Tuesday, 20 December 2022 at 21:50
>>>>> To: Russ Housley <[e-mail]>, Sean Turner <[e-mail]>, Daniel Migault <[e-mail]>
>>>>> Cc: RFC Editor <[e-mail]>, John Mattsson <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail]<[e-mail]>, Roman D. Danyliw <[e-mail]>, [e-mail] <[e-mail]>
>>>>> Subject: Re: AUTH48: RFC-to-be 9310 <draft-ietf-lamps-5g-nftypes-08> for your review
>>>>> Hi, Russ, Sean, and Daniel.
>>>>> 
>>>>> Thank you for your prompt replies!
>>>>> 
>>>>> Russ, thank you for addressing our questions so quickly!  We have updated this document per your notes below.
>>>>> 
>>>>> Regarding this item:
>>>>> 
>>>>>>> NF type(s) / NF Type(s) / NFType(s) (in running text, e.g.,
>>>>>>> "each NF type", "Each NFType", "that specify the NF Types",
>>>>>>> "If the NFTypes contain")
>>>>>> 
>>>>>> The term "NFTypes" is used to refer to the ASN.1 defined type.
>>>>>> 
>>>>>> The term "NF Types" is used to refer the network function defined by 3GPP.
>>>>> 
>>>>> We did not make any changes.  Please let us know if we missed anything.
>>>>> 
>>>>> 
>>>>> The latest files are posted here (you may need to refresh your browser):
>>>>> 
>>>>>  https://www.rfc-editor.org/authors/rfc9310.txt
>>>>>  https://www.rfc-editor.org/authors/rfc9310.pdf
>>>>>  https://www.rfc-editor.org/authors/rfc9310.html
>>>>>  https://www.rfc-editor.org/authors/rfc9310.xml
>>>>>  https://www.rfc-editor.org/authors/rfc9310-diff.html
>>>>>  https://www.rfc-editor.org/authors/rfc9310-rfcdiff.html
>>>>>  https://www.rfc-editor.org/authors/rfc9310-auth48diff.html
>>>>> 
>>>>>  https://www.rfc-editor.org/authors/rfc9310-xmldiff1.html
>>>>>  https://www.rfc-editor.org/authors/rfc9310-xmldiff2.html
>>>>> 
>>>>> Please let us know whether you approve this document in its current form or additional updates are needed.
>>>>> 
>>>>> Please note that I will be at work tomorrow and then will be away for the Holidays.
>>>>> 
>>>>> Thanks again!
>>>>> 
>>>>> RFC Editor/lb
>>>>> 
>>>>>> On Dec 20, 2022, at 9:27 AM, Daniel Migault <daniel.migault=[e-mail]> wrote:
>>>>>> 
>>>>>> Same for me. Thanks for handling this.
>>>>>> Yours,
>>>>>> Daniel
>>>>> 
>>>>> ...
>>>>> 
>>>>>> On Dec 20, 2022, at 9:26 AM, Sean Turner <[e-mail]> wrote:
>>>>>> 
>>>>>> All of these seem fine to me.
>>>>>> 
>>>>>>> On Dec 20, 2022, at 12:02, Russ Housley <[e-mail]> wrote:
>>>>> 
>>>>> ...
>>>>> 
>>>>>> On Dec 20, 2022, at 9:02 AM, Russ Housley <[e-mail]> wrote:
>>>>>> 
>>>>>> 
>>>>>>> 1) <!-- [rfced] Running (abbreviated) document title (as seen in PDF
>>>>>>> output):  Should "5G NFType in ..." be "5G NFTypes in ..."?
>>>>>>> 
>>>>>>> Original:
>>>>>>> 5G NFType in X.509 Certificates -->
>>>>>> 
>>>>>> Please use "5G NFTypes in ..."
>>>>>> 
>>>>>>> 2) <!-- [rfced] Author names:  Per feedback from John Preuß Mattsson
>>>>>>> for RFC 9175 (and per RFC 9191), we updated John's name so that the
>>>>>>> listing on the first page matches those for RFCs 9175 and 9191.
>>>>>>> Please let us know any concerns.
>>>>>>> 
>>>>>>> Original:
>>>>>>> J. P. Mattsson
>>>>>>> 
>>>>>>> Currently:
>>>>>>> J. Preuß Mattsson -->
>>>>>> 
>>>>>> I assume that is fine with John.  That is fine with me.
>>>>>> 
>>>>>>> 3) <!-- [rfced] Please insert any keywords (beyond those that appear in the
>>>>>>> title) for use on <https://www.rfc-editor.org/search>. -->
>>>>>> 
>>>>>> Digital Certificate.
>>>>>> 
>>>>>>> 4) <!-- [rfced] Section 3:  Should the section title be "NFTypes
>>>>>>> Certificate Extension" instead of "Network Functions Certificate
>>>>>>> Extension"?
>>>>>>> 
>>>>>>> Original:
>>>>>>> 3.  Network Functions Certificate Extension -->
>>>>>> 
>>>>>> I think it would be better to use "Network Function Types Certificate Extension"
>>>>>> 
>>>>>>> 5) <!-- [rfced] Should any of the <artwork> elements in this document
>>>>>>> be changed to <sourcecode>?  Please see
>>>>>>> <https://www.rfc-editor.org/materials/sourcecode-types.txt>.  Also,
>>>>>>> if <https://www.rfc-editor.org/materials/sourcecode-types.txt>
>>>>>>> does not contain an applicable type, please let us know. -->
>>>>>> 
>>>>>> Yes.  In Section 3, the artwork is ASN.1 source code. However, it is repeated in Section 4, where it is already marked as ASN.1 source code.
>>>>>> 
>>>>>> 
>>>>>>> 6) <!-- [rfced] Normative References:  [TS23.003] is not cited anywhere
>>>>>>> in the document.  Please let us know where it should be cited.
>>>>>>> 
>>>>>>> Original:
>>>>>>> [TS23.003] 3rd Generation Partnership Project, "Technical
>>>>>>>         Specification Group Core Network and Terminals; Numbering,
>>>>>>>         addressing and identification (Release 17)", 3GPP
>>>>>>>         TS:23.003 V17.5.0 , March 2022,
>>>>>>>         <https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-88c49a0b61d7083d&q=1&e=2266d863-4c5f-425c-8672-663bd81b0d0a&u=https%3A%2F%2Fwww.3gpp.org%2Fftp%2FSpecs%2F
>>>>>>>         archive/23_series/23.003/23003-h50.zip>. -->
>>>>>> 
>>>>>> This can be dropped.  It was previously cited, but that text was dropped from the document.
>>>>>> 
>>>>>>> 7) <!-- [rfced] Appendix B:  Would you like to use "id-kp-clientAuth"
>>>>>>> instead of "clientAuth"?  We ask because all other such "OBJECT
>>>>>>> IDENTIFIER" entries in this section seem to match up pretty well.
>>>>>>> 
>>>>>>> Original:
>>>>>>> 06   8:        OBJECT IDENTIFIER clientAuth (1 3 6 1 5 5 7 3 2) -->
>>>>>> 
>>>>>> The program that was used to "dump" the certificate uses short forms of all of the extension names.  I would have to edit all of them, not just clientAuth.  I think we should leave this alone.
>>>>>> 
>>>>>>> 8) <!-- [rfced] Please review the "Inclusive Language" portion of the
>>>>>>> online Style Guide at
>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
>>>>>>> and let us know if any changes are needed.
>>>>>>> 
>>>>>>> Note that our script did not flag any words in particular, but this
>>>>>>> should still be reviewed as a best practice. -->
>>>>>> 
>>>>>> I do not see any language that causes concern.
>>>>>> 
>>>>>>> 9) <!-- [rfced] Please let us know if any changes are needed for the
>>>>>>> following:
>>>>>>> 
>>>>>>> a) The following terms appear to be used inconsistently in this
>>>>>>> document.  Please let us know which form is preferred.
>>>>>>> 
>>>>>>> 5G System / 5G system (in running text)
>>>>>> 
>>>>>> Please use 5G System
>>>>>> 
>>>>>>> ASN.1 module / ASN.1 Module (in running text)
>>>>>>> (e.g., "an ASN.1 module", "the ASN.1 Module")
>>>>>> 
>>>>>> Please use ASN.1 Module
>>>>>> 
>>>>>>> id-pe-nftype / id-pe-nftypes (We ask because the same OID value
>>>>>>> is shown for both spellings.  Also, please note that IANA uses
>>>>>>> the latter form on
>>>>>>> <https://www.iana.org/assignments/smi-numbers/smi-numbers.txt>;
>>>>>>> are both forms correct?)
>>>>>> 
>>>>>> In Section 3, please use "id-pe-nftype" to make it match the rest of the document.
>>>>>> 
>>>>>>> Side note:  We also see "id-mod-nftype" (i.e., the singular form
>>>>>>>  "nftype".)
>>>>>> 
>>>>>> The singular is correct.
>>>>>> 
>>>>>>> NF type(s) / NF Type(s) / NFType(s) (in running text, e.g.,
>>>>>>> "each NF type", "Each NFType", "that specify the NF Types",
>>>>>>> "If the NFTypes contain")
>>>>>> 
>>>>>> The term "NFTypes" is used to refer to the ASN.1 defined type.
>>>>>> 
>>>>>> The term "NF Types" is used to refer the network function defined by 3GPP.
>>>>>> 
>>>>>>> NFType certificate extension (2 instances) /
>>>>>>> NFTypes certificate extension (11 instances)
>>>>>> 
>>>>>> Please use "NFTypes certificate extension" in all places.
>>>>>> 
>>>>>>> subjectAltName certificate extension /
>>>>>>> SubjectAltName certificate extension (running text in
>>>>>>>  Section 1 and Appendix B)
>>>>>> 
>>>>>> Please use "SubjectAltName certificate extension" in all places.
>>>>>> 
>>>>>>> b) Would you like spacing before the instances of "::=" to be
>>>>>>> consistent?
>>>>>>> 
>>>>>>> For example,
>>>>>>> id-pe-nftypes  OBJECT IDENTIFIER  ::=
>>>>>>> ...
>>>>>>> NFTypes ::= SEQUENCE SIZE
>>>>>>> ... -->
>>>>>> 
>>>>>> One space is fine.
>>>>>> 
>>>>>> Russ
>>>>>> 
>>> <rfc9310-JPM.xml>
>> 
>