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

[Di Ma <[e-mail]>]

Francis,

Thanks for your review.

Please see my response in lines.


> 在 2018年2月27日，00:24，Francis Dupont <[e-mail]> 写道：
> 
> 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