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

[John Mattsson <[e-mail]>]

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://www.3gpp.org/ftp/Specs/
              archive/29_series/29.510/29510-h50.zip>.
NEW:
              17)", 3GPP TS:29.510 V17.8.0, December 2022,
              <https://www.3gpp.org/ftp/Specs/
              archive/29_series/29.510/29510-h80.zip>.

OLD:
              (Release 17)", 3GPP TS:33.310 V17.2.0, March 2022,
              <https://www.3gpp.org/ftp/Specs/
              archive/33_series/33.310/33310-h20.zip>.
NEW:
              (Release 17)", 3GPP TS:33.310 V17.4.0, September 2022,
              <https://www.3gpp.org/ftp/Specs/
              archive/33_series/33.310/33310-h40.zip>.

OLD:
              (Release 17)", 3GPP TS:29.571 V17.5.0, March 2022,
              <https://www.3gpp.org/ftp/Specs/
              archive/29_series/29.571/29571-h50.zip>.
NEW:
              (Release 17)", 3GPP TS:29.571 V17.8.0, December 2022,
              <https://www.3gpp.org/ftp/Specs/
              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
>