Francis, Thanks for your review.
Please see my response in lines. > 在 2018年2月27日，00:24，Francis Dupont <francis.dup...@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 _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
