Re: [auth48] AUTH48: RFC-to-be 9563 <draft-cuiling-dnsop-sm2-alg-15> for your review

[zhangcuiling <[e-mail]>]

Hi RFC Editor,

Thanks for your proofreading.

Besides the raised questions, I've found that "D" is missing in "DNSSEC" in the title.
(https://www.rfc-editor.org/authors/rfc9563.txt). Please adjust it.
OLD:
SM2 Digital Signature Algorithm for NSSEC
NEW:
SM2 Digital Signature Algorithm for DNSSEC

Answers for questions are as follows.

Best regards,
Cathy
  
> From: rfc-editor <[e-mail]>
> Date: 2024-04-13 07:13
> To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
> CC: <[e-mail]>, <[e-mail]>, <[e-mail]>
> Subject: Re: AUTH48: RFC-to-be 9563 <draft-cuiling-dnsop-sm2-alg-15> for your review

>Authors,
>
>While reviewing this document during AUTH48, please resolve (as necessary)
>the following questions, which are also in the XML file.
>
>1) <!-- [rfced] May we set sortRefs to true so the references will appear
>in alphanumeric order? -->
> 

Of course, please.

>
>2) <!-- [rfced] The abbreviated title includes "DNSS".  Please confirm this
>is correct, as we do not find instances of "DNSS" in the RFC Series. 
>
><title abbrev="SM2 Digital Signature Algorithm for DNSS">
>-->
>

Sorry, it's a mistake. The last word should be "DNSSEC".

>
>3) <!-- [rfced] Please insert any keywords (beyond those that appear in
>the title) for use on https://www.rfc-editor.org/search. -->
>

No additions.

>
>4) <!-- [rfced] The following artwork extends beyond the 72 character margin by 4 characters.  Please review and let us know how the lines may be broken. 
>
>p  = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 00000000 FFFFFFFF FFFFFFFF
>a  = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 00000000 FFFFFFFF FFFFFFFC
>b  = 28E9FA9E 9D9F5E34 4D5A9E4B CF6509A7 F39789F5 15AB8F92 DDBCBD41 4D940E93
>xG = 32C4AE2C 1F198119 5F990446 6A39C994 8FE30BBF F2660BE1 715A4589 334C74C7
>yG = BC3736A2 F4F6779C 59BDCEE3 6B692153 D0A9877C C62A4740 02DF32E5 2139F0A0
>n  = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF 7203DF6B 21C6052B 53BBF409 39D54123
>-->
>

Please replace them with the following lines.
p  = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF 
     FFFFFFFF 00000000 FFFFFFFF FFFFFFFF
a  = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
     FFFFFFFF 00000000 FFFFFFFF FFFFFFFC
b  = 28E9FA9E 9D9F5E34 4D5A9E4B CF6509A7
     F39789F5 15AB8F92 DDBCBD41 4D940E93
xG = 32C4AE2C 1F198119 5F990446 6A39C994
     8FE30BBF F2660BE1 715A4589 334C74C7
yG = BC3736A2 F4F6779C 59BDCEE3 6B692153
     D0A9877C C62A4740 02DF32E5 2139F0A0
n  = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
     7203DF6B 21C6052B 53BBF409 39D54123

>
>5) <!-- [rfced] Does the "above algorithm" refer to the digital signature algorithm, and is this different from the digital signature generation algorithm? 
>
>Original:
>   Conformant implementations that create records to be put into the DNS
>   MAY implement signing and verification for the above algorithm.
>   Conformant DNSSEC verifiers MAY implement verification for the above
>   algorithm.
>-->
>

Yes, "above algorithm" refers to the digital signature algorithm,
and it's the same as the digital signature generation algorithm . 
Please replace "above algorithm" with "SM2 digital signature algorithm".

>
>6) <!-- [rfced] It's unclear why some of the example text in Section 6 was
>formatted as a definition list <dl> and some as <artwork>.  We have
>combined the text into one <artwork> block.  However, we wonder whether
>this should be <sourcecode>, perhaps with type="dns-rr". 
>
>The current list of preferred <sourcecode> values for "type" is available
>at https://www.rfc-editor.org/materials/sourcecode-types.txt. If the
>current list does not contain an applicable type, feel free to suggest
>additions for consideration. Note that it is also acceptable to leave the
>"type" attribute not set.
>
>Please review the output carefully and pay particular attention to line
>breaks and wrapping.
>-->
>

Thanks for your advice. Please change it to <sourcecode> with type="dns-rr".
And please adjust as follows:

Closing parenthesis missing here：
OLD:
example. 0  IN   RRSIG    NSEC3PARAM 17 1 0 (
       20230901000000 20220901000000 65042 example.
       aqntwEYEJzkVb8SNuJLwdx7f+vivv5IUIeAj
NEW:
example. 0  IN   RRSIG    NSEC3PARAM 17 1 0 (
       20230901000000 20220901000000 65042 example.
       aqntwEYEJzkVb8SNuJLwdx7f+vivv5IUIeAj )

Please remove blank line for the following paragraphs:
OLD:
62KP1QB93KRGR6LM7SEVPJVNG90BLUE8.example. 3600 IN NSEC3  1 1 10
    AABBCCDD (

    GTGVQIILTSSJ8FFO9J6DC8PRTFAEA8G2 NS SOA RRSIG DNSKEY NSEC3PARAM )

NEW:
62KP1QB93KRGR6LM7SEVPJVNG90BLUE8.example. 3600 IN NSEC3  1 1 10
    AABBCCDD (
    GTGVQIILTSSJ8FFO9J6DC8PRTFAEA8G2 NS SOA RRSIG DNSKEY NSEC3PARAM )

OLD:
62KP1QB93KRGR6LM7SEVPJVNG90BLUE8.example. 3600 IN RRSIG  NSEC3 17 2
    3600 (

    20230901000000 20220901000000 65042 example.
    FOWLegTgFkFY9vCOo4kHwjEvZ+IL1NMl4s9V
    hVyPOwokd5uOLKeXTP19HIeEtW73WcJ9XNe/ ie/knp7Edo/hxw== )

NEW:
62KP1QB93KRGR6LM7SEVPJVNG90BLUE8.example. 3600 IN RRSIG  NSEC3 17 2
    3600 (
    20230901000000 20220901000000 65042 example.
    FOWLegTgFkFY9vCOo4kHwjEvZ+IL1NMl4s9V
    hVyPOwokd5uOLKeXTP19HIeEtW73WcJ9XNe/ ie/knp7Edo/hxw== )

>
>7) <!-- [rfced] We were unable to verify the reference information at these
>locations, as the sites were timing out.  We will try again later.  Please
>let us know if there are other URLs that should be used.
>
>[GBT-32905-2016] http://www.gmbz.org.cn/upload/2018-07-24/1532401392982079739.pdf
>[GBT-32918.1-2016] http://www.gmbz.org.cn/upload/2018-07-24/1532401673134070738.pdf
>[GBT-32918.2-2016] http://www.gmbz.org.cn/upload/2018-07-24/1532401673138056311.pdf
>-->
>

I've just tried and it seems the website works well at this time.
Could you please try it again?

>
>8) <!-- [rfced] Please review the "Inclusive Language" portion of the
>online Style Guide <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.
>-->
>

find no problems of such kind.

>
>Thank you.
>
>RFC Editor
>
>
>On Apr 12, 2024, at 4:08 PM, [e-mail] wrote:
>
>*****IMPORTANT*****
>
>Updated 2024/04/12
>
>RFC Author(s):
>--------------
>
>Instructions for Completing AUTH48
>
>Your document has now entered AUTH48.  Once it has been reviewed and
>approved by you and all coauthors, it will be published as an RFC. 
>If an author is no longer available, there are several remedies
>available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>
>You and you coauthors are responsible for engaging other parties
>(e.g., Contributors or Working Group) as necessary before providing
>your approval.
>
>Planning your review
>---------------------
>
>Please review the following aspects of your document:
>
>*  RFC Editor questions
>
>   Please review and resolve any questions raised by the RFC Editor
>   that have been included in the XML file as comments marked as
>   follows:
>
>   <!-- [rfced] ... -->
>
>   These questions will also be sent in a subsequent email.
>
>*  Changes submitted by coauthors
>
>   Please ensure that you review any changes submitted by your
>   coauthors.  We assume that if you do not speak up that you
>   agree to changes submitted by your coauthors.
>
>*  Content
>
>   Please review the full content of the document, as this cannot
>   change once the RFC is published.  Please pay particular attention to:
>   - IANA considerations updates (if applicable)
>   - contact information
>   - references
>
>*  Copyright notices and legends
>
>   Please review the copyright notice and legends as defined in
>   RFC 5378 and the Trust Legal Provisions
> (TLP – https://trustee.ietf.org/license-info/).
>
>*  Semantic markup
>
>   Please review the markup in the XML file to ensure that elements of 
>   content are correctly tagged.  For example, ensure that <sourcecode>
>   and <artwork> are set correctly.  See details at
> <https://authors.ietf.org/rfcxml-vocabulary>.
>
>*  Formatted output
>
>   Please review the PDF, HTML, and TXT files to ensure that the
>   formatted output, as generated from the markup in the XML file, is
>   reasonable.  Please note that the TXT will have formatting
>   limitations compared to the PDF and HTML.
>
>
>Submitting changes
>------------------
>
>To submit changes, please reply to this email using ‘REPLY ALL’ as all
>the parties CCed on this message need to see your changes. The parties
>include:
>
>   *  your coauthors
>  
>   *  [e-mail] (the RPC team)
>
>   *  other document participants, depending on the stream (e.g.,
>      IETF Stream participants are your working group chairs, the
>      responsible ADs, and the document shepherd).
>    
>   *  [e-mail], which is a new archival mailing list
>      to preserve AUTH48 conversations; it is not an active discussion
>      list:
>    
>     *  More info:
> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>    
>     *  The archive itself:
> https://mailarchive.ietf.org/arch/browse/auth48archive/
>
>     *  Note: If only absolutely necessary, you may temporarily opt out
>        of the archiving of messages (e.g., to discuss a sensitive matter).
>        If needed, please add a note at the top of the message that you
>        have dropped the address. When the discussion is concluded,
>        [e-mail] will be re-added to the CC list and
>        its addition will be noted at the top of the message.
>
>You may submit your changes in one of two ways:
>
>An update to the provided XML file
> — OR —
>An explicit list of changes in this format
>
>Section # (or indicate Global)
>
>OLD:
>old text
>
>NEW:
>new text
>
>You do not need to reply with both an updated XML file and an explicit
>list of changes, as either form is sufficient.
>
>We will ask a stream manager to review and approve any changes that seem
>beyond editorial in nature, e.g., addition of new text, deletion of text,
>and technical changes.  Information about stream managers can be found in
>the FAQ.  Editorial changes do not require approval from a stream manager.
>
>
>Approving for publication
>--------------------------
>
>To approve your RFC for publication, please reply to this email stating
>that you approve this RFC for publication.  Please use ‘REPLY ALL’,
>as all the parties CCed on this message need to see your approval.
>
>
>Files
>-----
>
>The files are available here:
> https://www.rfc-editor.org/authors/rfc9563.xml
> https://www.rfc-editor.org/authors/rfc9563.html
> https://www.rfc-editor.org/authors/rfc9563.pdf
> https://www.rfc-editor.org/authors/rfc9563.txt
>
>Diff file of the text:
> https://www.rfc-editor.org/authors/rfc9563-diff.html
> https://www.rfc-editor.org/authors/rfc9563-rfcdiff.html (side by side)
>
>Diff of the XML:
> https://www.rfc-editor.org/authors/rfc9563-xmldiff1.html
>
>The following files are provided to facilitate creation of your own
>diff files of the XML. 
>
>Initial XMLv3 created using XMLv2 as input:
> https://www.rfc-editor.org/authors/rfc9563.original.v2v3.xml
>
>XMLv3 file that is a best effort to capture v3-related format updates
>only:
> https://www.rfc-editor.org/authors/rfc9563.form.xml
>
>
>Tracking progress
>-----------------
>
>The details of the AUTH48 status of your document are here:
> https://www.rfc-editor.org/auth48/rfc9563
>
>Please let us know if you have any questions. 
>
>Thank you for your cooperation,
>
>RFC Editor
>
>--------------------------------------
>RFC9563 (draft-cuiling-dnsop-sm2-alg-15)
>
>Title            : SM2 Digital Signature Algorithm for DNSSEC
>Author(s)        : C. Zhang, Y. Liu, F. Leng, Q. Zhao, Z. He
>WG Chair(s)      :
>Area Director(s) :
>
>
>