Re: [auth48] AUTH48: RFC-to-be 9310 <draft-ietf-lamps-5g-nftypes-08> for your review
Russ Housley <housley@vigilsec.com> Thu, 22 December 2022 16:17 UTC
Return-Path: <housley@vigilsec.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 6FBB1C1522A7; Thu, 22 Dec 2022 08:17:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jJYs2U9pfAXP; Thu, 22 Dec 2022 08:17:00 -0800 (PST)
Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (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 A5FE6C1516E1; Thu, 22 Dec 2022 08:17:00 -0800 (PST)
Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id 36C7C14F86B; Thu, 22 Dec 2022 11:16:59 -0500 (EST)
Received: from a860b60074bd.fios-router.home (unknown [96.241.2.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id BD8A414F754; Thu, 22 Dec 2022 11:16:58 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <CF3646AE-FD26-495E-8801-65141F234401@amsl.com>
Date: Thu, 22 Dec 2022 11:16:58 -0500
Cc: John Mattsson <john.mattsson@ericsson.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: <D8771B37-45A1-48CB-8B67-C321597E247D@vigilsec.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> <CF3646AE-FD26-495E-8801-65141F234401@amsl.com>
To: Lynne Bartholomew <lbartholomew@amsl.com>
X-Mailer: Apple Mail (2.3445.104.21)
X-Scanned-By: mailmunge 3.10 on 66.39.134.11
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/yfUYEoqK-cjhC3zkRF7iWIgU7oo>
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: Thu, 22 Dec 2022 16:17:06 -0000
Looks good to me. Please proceed with publication. Russ > On Dec 21, 2022, at 6:43 PM, Lynne Bartholomew <lbartholomew@amsl.com> wrote: > > 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