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

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

 - 1 page 3: please expand the TA abbrev (it is the only occurrence BTW).

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

 - 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...)

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

 - 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?)

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

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

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

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

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

 - 3.4.2 page 8: please introduce the SKI abbrev.

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

 - 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

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

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

 - 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 (:-).

Regards

Francis.Dupont@fdupont.fr