Re: [Gen-art] review of draft-ietf-sidr-slurm-06.txt

Di Ma <madi@zdns.cn> Tue, 27 February 2018 11:50 UTC

Return-Path: <madi@zdns.cn>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B4B126DFF for <gen-art@ietfa.amsl.com>; Tue, 27 Feb 2018 03:50:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7prYFLMa7qV8 for <gen-art@ietfa.amsl.com>; Tue, 27 Feb 2018 03:50:14 -0800 (PST)
Received: from smtpbgeu1.qq.com (smtpbgeu1.qq.com [52.59.177.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 228B0126BF0 for <gen-art@ietf.org>; Tue, 27 Feb 2018 03:50:12 -0800 (PST)
X-QQ-mid: bizesmtp15t1519732207tqviadpx
Received: from [192.168.3.3] (unknown [117.100.128.114]) by esmtp4.qq.com (ESMTP) with id ; Tue, 27 Feb 2018 19:50:05 +0800 (CST)
X-QQ-SSF: 00400000004000F0FG40000A0000000
X-QQ-FEAT: 9MsTBLS6yXEf8qZ4zHn33qOvV77vjelWo3KE3WrZfUCa80S+MV3k/50HG2U63 5ngl5yJSTjmxv7znur50wO8lfDlLRo/rANhJpeM7870bwFQfjz3YKs2wb5vGazmPics88Op HcYbgferOegn42vtIZHA1IQsjidZvPkQzWBEwPXAiSW8pBjIlN9agR4MvnDc5a6Bp3BTyJQ d0vcgpdqxS0Qkzoi/sxzFvLh8aQUNWX1EfjB8Op3xP59tMYXMjEA7kawvZvGGKxokiVCf98 6+Wwi0rQGvVYvPCAgxSUgn4oyYX4MD/ILy/n5c6ztaO9hh
X-QQ-GoodBg: 2
Content-Type: text/plain; charset=gb2312
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Di Ma <madi@zdns.cn>
In-Reply-To: <201802261624.w1QGOKdk042835@givry.fdupont.fr>
Date: Tue, 27 Feb 2018 19:50:04 +0800
Cc: gen-art@ietf.org, draft-ietf-sidr-slurm.all@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <722C0EA6-A247-4A65-84AC-52C07BA17180@zdns.cn>
References: <201802261624.w1QGOKdk042835@givry.fdupont.fr>
To: Francis Dupont <Francis.Dupont@fdupont.fr>
X-Mailer: Apple Mail (2.3445.5.20)
X-QQ-SENDSIZE: 520
Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign1
X-QQ-Bgrelay: 1
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/KVOnX_3EsQ_E7jxyDF8CkGqfbL0>
Subject: Re: [Gen-art] review of draft-ietf-sidr-slurm-06.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Feb 2018 11:50:20 -0000

Francis,

Thanks for your review.

Please see my response in lines.


> 在 2018年2月27日,00:24,Francis Dupont <Francis.Dupont@fdupont.fr> 写道:
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-sidr-slurm-06.txt
> Reviewer: Francis Dupont
> Review Date: 20180217
> IETF LC End Date: 20180221
> IESG Telechat date: unknown
> 
> Summary: Ready
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments: 
> - ToC page 2 and 6 page 14 (title): Security considerations ->
>  Security Considerations

Accepted. 

> 
> - ToC page 2 and 7 page 14: Acknowledgements -> Acknowledgments

I think both kinds of spell are okay :-)
> 
> - 1 page 3: please expand the TA abbrev (it is the only occurrence BTW).

Okay. We will use Trust Anchor for its first use. 

> 
> - 1.1. page 3: add a reference to RFC 8174 which updates RFC 2119 fixing
>  the keyword case silly issue.

Good idea.

> 
> - 2 page 3: please introduce the RP abbrev before (RP is not well known
>  because it has 4 different meanings. Here it is not ambiguous but
>  for instance RP does not stand for the beginning of RPKI…)

Yes. We will use Relaying Party for its first use. 


> 
> - 3.1 page 4: [RFC8259]format -> [RFC8259]format (missing space).

Good catch.

> 
> - 3.1 page 4: for me the right reference to JSON specs is ECMA-404.
>  Now I don't know the policy of the IETF about this particular point
>  (anyway if this must be fixed this will be by the RFC Editor?)

I would rather leave this issue to the RFC Editor.

> 
> - 3.2 page 5: I leave the choice to introduce FQDN to you (for me
>  it is more than well known but it is not in RFC Editor list
>  https://www.rfc-editor.org/materials/abbrev.expansion.txt)

Okay. We will change it into Fully Qualified Domain Name. 

> 
> - 3.2 page 5: MUST in “ all targets must be acceptable"?


Good catch.

> 
> - 3.3 page 6 example 1: "asn": 65536 -> "asn": 65536,
>  (missing comma which leads to incorrect JSON)

Yes. We will correct it. 

> 
> - 3.3 page 7 example 2: another missing comma at the same position.

Still yes. 

> 
> - 3.4.1 page 7: I have no idea whether "subsume" is common English or not,
>  one of the authors is from China so I believe it is…

I think ‘subsume’ is okay here -:) 


> 
> - 3.4.2 page 8: please introduce the SKI abbrev.

I believe the document has articulated as in: 

The Router SKI is the Base64 [RFC4648] encoding of a router certificate’s Subject Key Identifier…

> 
> - 3.4.2 page 8 and 3.5.2 page 10: the document does not specify what
>  is the encoding. I suppose it is BER? If you believe it is not useful
>  you can keep the document as it is (i.e. not adding new encoding details).
>  Note for the public key 3.5.2 says DER.

It is DER. 
> 
> - 3.6 pages 11 and 12: there are JSON pretty-printers available if you
>  like (I even have one :-). (I don't mean 3.6 JSON is not well indented,
>  just signal there are tools in the case you don’t already know).
> 
> - 4.2 page 13 (twice): Y,Z -> Y, Z

Good catch. 

> 
> - 6 page 14: strange (to me) comma in “by the RPKI, to that RP."

‘to that RP’ is used as accompany adverbial, indicating the outcome. 

> 
> - authors’ addresses page 17: China -> PR China or CN

I think ‘China' is okay.

Yet we can make the change, using  P.R.China. 

> 
> - authors' addresses page 17: I am not sure that to be affilated to
>  his own personal organization is to be "unaffiliated"... IMHO the
>  problem is the XML schema requires the organization field to be set (:-).


David has replied :-)

Di