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

Lynne Bartholomew <lbartholomew@amsl.com> Tue, 20 December 2022 20:49 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 A2AD4C14F747; Tue, 20 Dec 2022 12:49:43 -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 y1CsRcrMq9N7; Tue, 20 Dec 2022 12:49:39 -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 37B5EC14F5E1; Tue, 20 Dec 2022 12:49:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 0B5074243EC3; Tue, 20 Dec 2022 12:49:39 -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 PEPykcIDUpSX; Tue, 20 Dec 2022 12:49:38 -0800 (PST)
Received: from smtpclient.apple (unknown [IPv6:2601:646:8b00:3f80:14b4:c738:649:a28f]) by c8a.amsl.com (Postfix) with ESMTPSA id C1BFC424FFEC; Tue, 20 Dec 2022 12:49:38 -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: <B8170B54-A720-41BE-A9D7-0AF6EE96C0BD@vigilsec.com>
Date: Tue, 20 Dec 2022 12:49:27 -0800
Cc: RFC Editor <rfc-editor@rfc-editor.org>, john.mattsson@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: <0B863161-56FD-434E-A62D-71A9915D802C@amsl.com>
References: <20221220002240.6268A1BA406F@rfcpa.amsl.com> <B8170B54-A720-41BE-A9D7-0AF6EE96C0BD@vigilsec.com>
To: Russ Housley <housley@vigilsec.com>, Sean Turner <sean@sn3rd.com>, daniel.migault@ericsson.com
X-Mailer: Apple Mail (2.3731.200.110.1.12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/IFXzbMGc36Kk-Y9o3f2tRGy04I4>
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 20:49:43 -0000

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