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

From: Francis Dupont <[email-masked]>
Date: Mon, 26 Feb 2018 17:24:20 +0100

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

[email-masked]

---

From: David Mandelberg <[email-masked]>
Date: Mon, 26 Feb 2018 12:31:25 -0500

>    problem is the XML schema requires the organization field to be set (:-).

I think that's a hold-over from when I worked for Google and didn't feel 
like going through Google's approval process to get permission to list 
my affiliation. Now, I do business under the legal entity David 
Mandelberg, LLC, but I never really intended to use that name anywhere 
other than taxes/banks/etc. Would it be better to list that instead of 
unaffiliated? Or maybe "self-employed" or some other phrase?

-- 
Freelance cyber security consultant, software developer, and more
https://david.mandelberg.org/

---

From: Di Ma <[email-masked]>
Date: Tue, 27 Feb 2018 19:50:04 +0800

Francis,

Thanks for your review.

Please see my response in lines.

> 在 2018年2月27日，00:24，Francis Dupont <[email-masked]> 写道：
> 

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. 

>  the keyword case silly issue.

Good idea.

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

>  (anyway if this must be fixed this will be by the RFC Editor?)

I would rather leave this issue to the RFC Editor.

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

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

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

>  Note for the public key 3.5.2 says DER.

It is DER. 
>  just signal there are tools in the case you don’t already know).
> 

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. 

>  problem is the XML schema requires the organization field to be set (:-).

David has replied :-)

Di