Re: [Sidrops] Éric Vyncke's No Objection on draft-ietf-sidrops-rp-06: (with COMMENT)

Stephen Kent <stkent@verizon.net> Thu, 09 April 2020 14:25 UTC

Return-Path: <stkent@verizon.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF1A3A0651 for <sidrops@ietfa.amsl.com>; Thu, 9 Apr 2020 07:25:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NP9ZUjXChKQn for <sidrops@ietfa.amsl.com>; Thu, 9 Apr 2020 07:25:16 -0700 (PDT)
Received: from sonic315-13.consmr.mail.bf2.yahoo.com (sonic315-13.consmr.mail.bf2.yahoo.com [74.6.134.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7A1A3A0640 for <sidrops@ietf.org>; Thu, 9 Apr 2020 07:25:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1586442315; bh=ukPkvZQYCulVtzCthPvDIXI6bH2rLj+ZPvtq7JEINsc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=cMnJvt8p8p74eN1/xy3UUSyoIIY2aYi+zqC1jVM0w2t6UMqmaezqAHAbjhq7yEOsuXPQKmPyytiliTFfW1947KadNjkGazt+8yOApSlwtPmdrT3tI4g5D3/RDd6hrvnwALDBThfxIXMN7A0v7vQFiLvfGjhC4VDo4QRDu8V2trERHmlmNQpOg9Zl/JM9siZT+UFkh5nQeCt1DAJ+svZNiNIqQHa0HFZK8otJtUEkEDo8lqBHfSAvltShFkWHJXvgy0qyVGh4x/uNP+AYFopd3Cm5/wngiz0eq4r3xwIdowgdJNjwX2xVZX1nkgpgLr77vcj2V6HRLj1H/BegYvCvig==
X-YMail-OSG: 39o.M1sVM1mpYRJeyVf1ie_yqNEv2iWeXxFX2qgRUzuXZifEWLpA6tnl0FIfDB_ i3a7RBEn70S_NTQINi0RGYwFcbtkrrD8.wawTeJygOeLnOBSpfYwj1zmUTxPy6zi7I9AuSvTxdHG ySMLYnoavQ0p0jpdNOP2M.GfqwwM4X7mqOIs9HPQaJExI_Lxwev95hPQBtv7svYIsj5mrObX4yIn EaXIm0VJe0H5NXolux.fyiRQwwXwWtFdIwrSztFc4Qzr4_HqxVrL_gZpP3ljhS9E.i0cp3PtkD8H XLdF.FjC_3A80mpTS6uE_9MoTczauo0fKZFwAsVPpibyFrrnF5FxHr.lHf5cRd9CaxzVFV8P6jjm 8kaqMsMHIOaenLkthANsU7.ArY4JJuFDG8tdaTI4YAd1hXsMLFpVYPOLr934TNSguwh6.kZfH8wu vpyMSO0sX5SR48FXELZhY_H_Y.x7qd3v6BtpORgBUs6mZ85ToYkTAmlVL7v43z8OlyHwvgyBLlrm BhwXvREbA6kKV9JBdGSjcrHYt0pzQbXiF.mQHS8sgCe.S.Qn7X0.qVqyNTw8YPj6KnMJJYeeHSFN w3S1LA0f8dK8Eic1LHHS5OnH5IeP8Bwxui7ev5MkrAlNnnAmF6sOKNYdMDEnsy2nlohfVVMsshLx bV..wCa9POVmuqBboDOZi_jv6AVv3uUKf3_d1uPvSMBvfMfOI7WdvuzHO9fJds21Q.TZ88CmIEZs pVy8YP06GNVcwy0.hRtHNtuUhT6iRgRtfgwgLEokpaOQJS1DcyyatDdr5JXreVyagHatq43oUyDD AqNNz.I3JYFIyUYtztiPt6AIAckLiru3cZlX7sO8SEVk4JtE8XPmNp0g.zdX9SKWhNZsihMwr8OG hgrUkedCsxz2j515O3r2bAMPD.ouwUz4J8pL51zN8wgUHcJfwTj71Zz5PZElRsh7FVqk.wmKnZh4 f6XC8DO08cWUFLQo.iUtwtuo4CWfRhij30kUHslz4997AecpiQ2tHFCZsdOy9QwKkv54psEaszPp .YgvmJYbe0Zktg.Mt_lkfpfmaHwe9N9lgPwHfTF5unQgpTFpdhxeGc2Xv6j293zNZZqD88syWbdw JNTkC9K.dw8NJGDKaS8q8rSc747TFF5q9DCi.XidgF5fIn7wprlFr0U8kQ4d0OSTDqVfoIl9gG7D HaBfnwy2Wy7z.9cA5YpmWh.jXatcHJrHPE0D.FAWOLi9yUr7IGfpazL7ORjcWsMUtRkt._4SDDz3 svTyEfCXUfukE2aKr0nndaqTGXNc.cCO3P7040RJaE2Jgx4IYJIf32alSzRMQngLQQ7weguBK6Q. uxGGDjlTKEFEP5Mcl3Wke8f7OYWoAuqV_wYczcCjTf5BjbnC.9i5Jw4XfTqShqgrEJk9.WG83f49 EIAobr9TsMebAZBxMZiKqMV.XO0Bspa7CO3Qbpma6y3Xmf4NRgQc6hO5Ft51bAjoMZc9Sfucspg- -
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Thu, 9 Apr 2020 14:25:15 +0000
Received: by smtp406.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 7697ad90edd7dbd15b5df9aa194deef6; Thu, 09 Apr 2020 14:25:13 +0000 (UTC)
To: =?UTF-8?Q?=c3=89ric_Vyncke?= <evyncke@cisco.com>, The IESG <iesg@ietf.org>
Cc: draft-ietf-sidrops-rp@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, Nathalie Trenaman <nathalie@ripe.net>
References: <158638167249.20283.18380733180622446749@ietfa.amsl.com>
From: Stephen Kent <stkent@verizon.net>
Message-ID: <133793a3-f1a0-a834-2f39-8ac6b7c1a628@verizon.net>
Date: Thu, 9 Apr 2020 10:25:12 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <158638167249.20283.18380733180622446749@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.15620 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/vTitmELbqrcunBSaDAJx9akRATE>
Subject: Re: [Sidrops] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sidrops-rp-06=3A_=28with_COMMENT=29?=
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Apr 2020 14:25:19 -0000

Éric,
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> While this document is useful for a RPKI newcomer or implementer, I wonder
> whether it should become a RFC even if informal... and the "requirements" in
> the title is also conflicting IMHO with an informational RFC.
Informational RFCs have been used to document requirements, separate 
from standards track RFCs, in many cases.  A quick scan of Informational 
RFCs published over the past 20 years, with titles including the word 
"requirements" identifies over 200 such documents. So I don't believe 
the use of that term in a title is disqualifying per se. Admittedly, 
these RFCs often were generated to provide guidance for later standards 
work, e.g., establishing a basis for a WG that is being formed. In this 
case, the motivation for a post hoc Informational RFC is the plethora of 
separate RFCs that establish processing criteria for an RP dealing with 
repository objects. The WG believes that this is a valid rationale for 
publication.
> I wonder whether the "security considerations" section is really about security
> considerations linked to this document or to the overall RP system.
The Security Considerations in this document are associated with relying 
party processing of data acquired from the repository system. There are 
a broader set of security considerations for the RPKI that address the 
behavior of the CAs and repository operators, not to mention how ISPs 
make use of the RPKI data after it has been validated.

Steve