[sidr] Alexey Melnikov's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT)

"Alexey Melnikov" <aamelnikov@fastmail.fm> Mon, 16 May 2016 18:45 UTC

Return-Path: <aamelnikov@fastmail.fm>
X-Original-To: sidr@ietf.org
Delivered-To: sidr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8B412D92C; Mon, 16 May 2016 11:45:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alexey Melnikov <aamelnikov@fastmail.fm>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.20.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160516184515.16709.44619.idtracker@ietfa.amsl.com>
Date: Mon, 16 May 2016 11:45:15 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/kTsJdHtM-GmMelKChtTko2Rx63s>
Cc: sidr@ietf.org, sidr-chairs@ietf.org, draft-ietf-sidr-rpsl-sig@ietf.org, sandy@tislabs.com
Subject: [sidr] Alexey Melnikov's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 May 2016 18:45:15 -0000

Alexey Melnikov has entered the following ballot position for
draft-ietf-sidr-rpsl-sig-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is a generally a well written document and I don't object to its
publication. However I have several minor but important points which
should be easy to address:

In Section 2.1:

  Reference to the certificate corresponding to the private key used to
sign this object (field "c"). The value of this field MUST be a URL of
type "rsync" or "http(s)"

You need to have Normative references for the corresponding URI RFCs: RFC
5781 for rsync URIs and RFC 7230 for http/https URIs.

  that points to a specific resource certificate in an RPKI repository
[RFC6481]. Any non URL-safe characters (including semicolon ";" and plus
"+") must be URL encoded.

This really need a Normative reference to RFC 3986.


  The signature itself (field "b"). This MUST be the last field in the
list. The signature is the output of the signature algorithm using the
appropriate private key and the calculated hash value of the object as
inputs. The value of this field is the digital signature in base64
encoding [RFC4648].

As RFC 4648 specifies 2 base64 alphabets, you need to include section
number. I think you meant Section 4 (and not Section 5).


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In Section 2.1:

  Time of signing (field "t"). The format of the value of this field MUST
be in the Internet Date/Time format [RFC3339]. All times MUST be
converted to Universal Coordinated Time (UTC)

To be pedantic, you should clarify that you mean the date-time ABNF
production with the timezone always being "Z".

In 3.1, inside numbered list (item 3):

* Converting all line endings to a single blank space.

Please include ASCII code for space, because " " is not very helpful,
especially considering that there are other Unicode space characters
which are not visually distinguishable. The same issue elsewhere in this
section.