Re: [auth48] AUTH48: RFC-to-be 9310 <draft-ietf-lamps-5g-nftypes-08> for your review
Lynne Bartholomew <lbartholomew@amsl.com> Wed, 21 December 2022 23:43 UTC
Return-Path: <lbartholomew@amsl.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC28C14F721; Wed, 21 Dec 2022 15:43:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hbw9SI0RPY2s; Wed, 21 Dec 2022 15:43:44 -0800 (PST)
Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FDD1C14F5E1; Wed, 21 Dec 2022 15:43:44 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id A4CD14243EC3; Wed, 21 Dec 2022 15:43:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCqFp8BtGej7; Wed, 21 Dec 2022 15:43:43 -0800 (PST)
Received: from smtpclient.apple (unknown [IPv6:2601:646:8b00:4460:8c7f:20ef:4f2d:cfbb]) by c8a.amsl.com (Postfix) with ESMTPSA id 6380E424FFE9; Wed, 21 Dec 2022 15:43:43 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\))
From: Lynne Bartholomew <lbartholomew@amsl.com>
In-Reply-To: <HE1PR0701MB30503FAA8200D8BD4653450289EB9@HE1PR0701MB3050.eurprd07.prod.outlook.com>
Date: Wed, 21 Dec 2022 15:43:32 -0800
Cc: Russ Housley <housley@vigilsec.com>, Sean Turner <sean@sn3rd.com>, Daniel Migault <daniel.migault@ericsson.com>, RFC Editor <rfc-editor@rfc-editor.org>, "lamps-ads@ietf.org" <lamps-ads@ietf.org>, "lamps-chairs@ietf.org" <lamps-chairs@ietf.org>, "tim.hollebeek@digicert.com" <tim.hollebeek@digicert.com>, "Roman D. Danyliw" <rdd@cert.org>, "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <CF3646AE-FD26-495E-8801-65141F234401@amsl.com>
References: <20221220002240.6268A1BA406F@rfcpa.amsl.com> <B8170B54-A720-41BE-A9D7-0AF6EE96C0BD@vigilsec.com> <0B863161-56FD-434E-A62D-71A9915D802C@amsl.com> <HE1PR0701MB30503FAA8200D8BD4653450289EB9@HE1PR0701MB3050.eurprd07.prod.outlook.com>
To: John Mattsson <john.mattsson@ericsson.com>
X-Mailer: Apple Mail (2.3731.200.110.1.12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/6dfIP68PFkeRjZ-wif8S7Rcu8jA>
Subject: Re: [auth48] AUTH48: RFC-to-be 9310 <draft-ietf-lamps-5g-nftypes-08> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Dec 2022 23:43:49 -0000
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 <john.mattsson@ericsson.com> 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 <lbartholomew@amsl.com> > Date: Wednesday, 21 December 2022 at 22:47 > To: John Mattsson <john.mattsson@ericsson.com> > Cc: Russ Housley <housley@vigilsec.com>, Sean Turner <sean@sn3rd.com>, Daniel Migault <daniel.migault@ericsson.com>, RFC Editor <rfc-editor@rfc-editor.org>, lamps-ads@ietf.org <lamps-ads@ietf.org>, lamps-chairs@ietf.org <lamps-chairs@ietf.org>, tim.hollebeek@digicert.com <tim.hollebeek@digicert.com>, Roman D. Danyliw <rdd@cert.org>, auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> > 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 <john.mattsson@ericsson.com> 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://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 <lbartholomew@amsl.com> > Date: Tuesday, 20 December 2022 at 21:50 > To: Russ Housley <housley@vigilsec.com>, Sean Turner <sean@sn3rd.com>, Daniel Migault <daniel.migault@ericsson.com> > Cc: RFC Editor <rfc-editor@rfc-editor.org>, John Mattsson <john.mattsson@ericsson.com>, lamps-ads@ietf.org <lamps-ads@ietf.org>, lamps-chairs@ietf.org <lamps-chairs@ietf.org>, tim.hollebeek@digicert.com <tim.hollebeek@digicert.com>, Roman D. Danyliw <rdd@cert.org>, auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> > 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=40ericsson.com@dmarc.ietf.org> wrote: > > > > Same for me. Thanks for handling this. > > Yours, > > Daniel > > ... > > > On Dec 20, 2022, at 9:26 AM, Sean Turner <sean@sn3rd.com> wrote: > > > > All of these seem fine to me. > > > >> On Dec 20, 2022, at 12:02, Russ Housley <housley@vigilsec.com> wrote: > > ... > > > On Dec 20, 2022, at 9:02 AM, Russ Housley <housley@vigilsec.com> 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 > >
- [auth48] AUTH48: RFC-to-be 9310 <draft-ietf-lamps… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9310 <draft-ietf-l… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9310 <draft-ietf-l… Russ Housley
- Re: [auth48] AUTH48: RFC-to-be 9310 <draft-ietf-l… Sean Turner
- Re: [auth48] AUTH48: RFC-to-be 9310 <draft-ietf-l… Daniel Migault
- Re: [auth48] AUTH48: RFC-to-be 9310 <draft-ietf-l… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9310 <draft-ietf-l… John Mattsson
- Re: [auth48] AUTH48: RFC-to-be 9310 <draft-ietf-l… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9310 <draft-ietf-l… John Mattsson
- Re: [auth48] AUTH48: RFC-to-be 9310 <draft-ietf-l… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9310 <draft-ietf-l… John Mattsson
- Re: [auth48] AUTH48: RFC-to-be 9310 <draft-ietf-l… Russ Housley
- Re: [auth48] AUTH48: RFC-to-be 9310 <draft-ietf-l… Russ Housley
- Re: [auth48] AUTH48: RFC-to-be 9310 <draft-ietf-l… John Mattsson
- Re: [auth48] AUTH48: RFC-to-be 9310 <draft-ietf-l… Sandy Ginoza
- Re: [auth48] AUTH48: RFC-to-be 9310 <draft-ietf-l… John Mattsson
- Re: [auth48] AUTH48: RFC-to-be 9310 <draft-ietf-l… Sean Turner
- Re: [auth48] AUTH48: RFC-to-be 9310 <draft-ietf-l… Russ Housley
- Re: [auth48] AUTH48: RFC-to-be 9310 <draft-ietf-l… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9310 <draft-ietf-l… Daniel Migault
- Re: [auth48] AUTH48: RFC-to-be 9310 <draft-ietf-l… Lynne Bartholomew