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

[John Mattsson <[e-mail]>]

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