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

[Daniel Migault <[e-mail]>]

Same for me. Thanks for handling this.
Yours,
Daniel

________________________________________
From: Sean Turner <[e-mail]>
Sent: Tuesday, December 20, 2022 12:26 PM
To: RFC Editor
Cc: Russ Housley; John Mattsson; Daniel Migault; [e-mail]; LAMPS Chairs; Tim Hollebeek; Roman Danyliw; [e-mail]
Subject: Re: AUTH48: RFC-to-be 9310 <draft-ietf-lamps-5g-nftypes-08> for your review

All of these seem fine to me.

> On Dec 20, 2022, at 12:02, Russ Housley <[e-mail]> 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-501d5122-313273af-454445555731-23a450388a88802a&q=1&e=1e3776f4-a801-4888-a60b-fc6af13c24b1&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
>