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

[Lynne Bartholomew <[e-mail]>]

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>
>