Re: [auth48] AUTH48: RFC-to-be 9310 <draft-ietf-lamps-5g-nftypes-08> for your review
Russ Housley <housley@vigilsec.com> Tue, 20 December 2022 17:02 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 9A728C14F731; Tue, 20 Dec 2022 09:02:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Level:
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 pzFJDgb33V9l; Tue, 20 Dec 2022 09:02:09 -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 2BF93C14F72A; Tue, 20 Dec 2022 09:02:09 -0800 (PST)
Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id 5A6C0173361; Tue, 20 Dec 2022 12:02:07 -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 E5C8B5B90D; Tue, 20 Dec 2022 12:02:06 -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: <20221220002240.6268A1BA406F@rfcpa.amsl.com>
Date: Tue, 20 Dec 2022 12:02:06 -0500
Cc: Sean Turner <sean@sn3rd.com>, john.mattsson@ericsson.com, daniel.migault@ericsson.com, lamps-ads@ietf.org, lamps-chairs@ietf.org, tim.hollebeek@digicert.com, "Roman D. Danyliw" <rdd@cert.org>, auth48archive@rfc-editor.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <B8170B54-A720-41BE-A9D7-0AF6EE96C0BD@vigilsec.com>
References: <20221220002240.6268A1BA406F@rfcpa.amsl.com>
To: RFC Editor <rfc-editor@rfc-editor.org>
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/hvH6HBs5Dc2RlBDoQYtoJmUZLo8>
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: Tue, 20 Dec 2022 17:02:13 -0000
> 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://www.3gpp.org/ftp/Specs/ > 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