Re: [auth48] AUTH48: RFC-to-be 9310 <draft-ietf-lamps-5g-nftypes-08> for your review
Sean Turner <sean@sn3rd.com> Tue, 20 December 2022 17:26 UTC
Return-Path: <sean@sn3rd.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 C9C71C14F735 for <auth48archive@ietfa.amsl.com>; Tue, 20 Dec 2022 09:26:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
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 mvKLkM9GAQA2 for <auth48archive@ietfa.amsl.com>; Tue, 20 Dec 2022 09:26:36 -0800 (PST)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 33AA7C14F72A for <auth48archive@rfc-editor.org>; Tue, 20 Dec 2022 09:26:36 -0800 (PST)
Received: by mail-qt1-x831.google.com with SMTP id x11so11455969qtv.13 for <auth48archive@rfc-editor.org>; Tue, 20 Dec 2022 09:26:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=SPRsP+MJrD1zLveN5jl35xwoR0VPNFwb/mDwb/pCPas=; b=I8igpeVHJRny6P4ZKJ+W9TcF4QV4K46LVbKe+qhSfDWCMnfWE1DjPfoii/jQbQlGNq KHT6qtPoOmoLppzaumetqyO0aL2VydpHyoTLH5dbuD/+CXN3jJDX7w5CLLNhOAPQh67N KkWB+DkmxoiJyuz/AH5TBxXolSchAxMq7UsqE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=SPRsP+MJrD1zLveN5jl35xwoR0VPNFwb/mDwb/pCPas=; b=aYbD71/AxshzomIAm9bloOPM/lHLdb0/R0AcoY2ZEWZpBcyB0NQCXGLn0itxUDhqrV /ftMwp+DsG01IbImyi/8LPzEsXlBT3JFH6mX00CpzzkEJk18zflzJyopVrYkadLxkLFc S7uNGw920PzRpv7rNZQmclzgUhw3GDxn3AozUWQXOEXiCB5JO4Yw18/bzDQwifRuOZwB fF3OwUEMBVl/MsHhmVte7vNTXMJ+IigQEvBH0qMq98eRsQeZ2DO95uhP5ZHBWdqdtVFk caUNKmh877aW1fLfFqI4tirtu+Z1php88m3Gn5mYyDgaAzRyingBUtyBboUXR9VmmwR1 jvCA==
X-Gm-Message-State: ANoB5plHfise01ikiz4xa/ZX3LWqjlzhzylwLauD9ZYRiaEfdtCcf1KB IEewa1STWVNlFePZAO6jhAVEAw==
X-Google-Smtp-Source: AA0mqf5PRM9FOUfOHVpp7jnTrk9Q37tKzPmZEzNRQSwfqY8o1a+6+2mXjAk056YYFviyRDeAGIjPeg==
X-Received: by 2002:ac8:5189:0:b0:3a7:f86a:a516 with SMTP id c9-20020ac85189000000b003a7f86aa516mr64043881qtn.10.1671557195194; Tue, 20 Dec 2022 09:26:35 -0800 (PST)
Received: from smtpclient.apple ([2600:4040:253b:7300:7d2c:1dcf:444b:abff]) by smtp.gmail.com with ESMTPSA id y9-20020ac81289000000b003a6947863e1sm7783052qti.11.2022.12.20.09.26.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Dec 2022 09:26:34 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Sean Turner <sean@sn3rd.com>
In-Reply-To: <B8170B54-A720-41BE-A9D7-0AF6EE96C0BD@vigilsec.com>
Date: Tue, 20 Dec 2022 12:26:33 -0500
Cc: Russ Housley <housley@vigilsec.com>, John Mattsson <john.mattsson@ericsson.com>, Daniel Migault <daniel.migault@ericsson.com>, lamps-ads@ietf.org, LAMPS Chairs <lamps-chairs@ietf.org>, Tim Hollebeek <tim.hollebeek@digicert.com>, Roman Danyliw <rdd@cert.org>, auth48archive@rfc-editor.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <EBADFF48-0454-4B7E-90BB-D9D18CCFC9DF@sn3rd.com>
References: <20221220002240.6268A1BA406F@rfcpa.amsl.com> <B8170B54-A720-41BE-A9D7-0AF6EE96C0BD@vigilsec.com>
To: RFC Editor <rfc-editor@rfc-editor.org>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/eXfb1CpqxJtLCoIUZna8ZzqdfZM>
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:26:40 -0000
All of these seem fine to me. > On Dec 20, 2022, at 12:02, 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://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