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

Francis Dupont <Francis.Dupont@fdupont.fr> Mon, 26 February 2018 16:50 UTC

Return-Path: <Francis.Dupont@fdupont.fr>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 77371126CC4; Mon, 26 Feb 2018 08:50:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ubNtIoTV_rlH; Mon, 26 Feb 2018 08:50:07 -0800 (PST)
Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79161126C26; Mon, 26 Feb 2018 08:50:07 -0800 (PST)
Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id w1QGOKdk042835; Mon, 26 Feb 2018 17:24:20 +0100 (CET) (envelope-from dupont@givry.fdupont.fr)
Message-Id: <201802261624.w1QGOKdk042835@givry.fdupont.fr>
From: Francis Dupont <Francis.Dupont@fdupont.fr>
To: gen-art@ietf.org
Cc: draft-ietf-sidr-slurm.all@ietf.org
Date: Mon, 26 Feb 2018 17:24:20 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/CVr307xZdAkaoJf_nuCUYMHaU2g>
Subject: [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: Mon, 26 Feb 2018 16:50:09 -0000

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


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

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