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

[Sandy Ginoza <[e-mail]>]

Hi Cathy,

Thank you for your reply.  Except from the references, we have updated the document as described below. The current files are available here: 
   https://www.rfc-editor.org/authors/rfc9563.xml
   https://www.rfc-editor.org/authors/rfc9563.txt
   https://www.rfc-editor.org/authors/rfc9563.pdf
   https://www.rfc-editor.org/authors/rfc9563.html

AUTH48 diffs: 
   https://www.rfc-editor.org/authors/rfc9563-auth48diff.html
   https://www.rfc-editor.org/authors/rfc9563-auth48rfcdiff.html (side by side) 

Comprehensive diffs: 
   https://www.rfc-editor.org/authors/rfc9563-diff.html
   https://www.rfc-editor.org/authors/rfc9563-rfcdiff.html (side by side)

Regarding the following references, we have not yet made any updates.

>> [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

The documents at these URLs don’t seem to include organization info, date of publication, etc. 
http://www.gmbz.org.cn shows the organization as Cryptograph Standardization Technical Committee.  We are seemingly able to find these documents on <https://www.chinesestandard.net/>, which has a title page that more closely matches the reference information provided in the reference entries.  Are these the same documents?  Are the original URLs provided in the Internet-Draft the freely available versions?  

[GBT-32905-2016] https://www.chinesestandard.net/PDF.aspx/GBT32905-2016
[GBT-32918.1-2016] https://www.chinesestandard.net/PDF.aspx/GBT32918.1-2016
  —> please confirm that “GB/T 32918.2-2016” should be “GB/T 32918.1-2016” for this entry (i.e., s/.2/.1)
[GBT-32918.2-2016] https://www.chinesestandard.net/PDF.aspx/GBT32918.2-2016

Thanks,
RFC Editor/sg 



> On Apr 14, 2024, at 7:21 PM, zhangcuiling <[e-mail]> wrote:
> 
> 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) :
>> 
>> 
>> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>