[sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT)
"Spencer Dawkins" <spencerdawkins.ietf@gmail.com> Thu, 16 February 2017 05:47 UTC
Return-Path: <spencerdawkins.ietf@gmail.com>
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 7BEFC1295AC; Wed, 15 Feb 2017 21:47:46 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.43.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148722406650.31533.1672555654116871127.idtracker@ietfa.amsl.com>
Date: Wed, 15 Feb 2017 21:47:46 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/LSlnUX9fCZaxhV8bZnvrut1isUw>
Cc: draft-ietf-sidr-delta-protocol@ietf.org, sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org
Subject: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-delta-protocol-07: (with 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: Thu, 16 Feb 2017 05:47:46 -0000
Spencer Dawkins has entered the following ballot position for draft-ietf-sidr-delta-protocol-07: No Objection 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-delta-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I’m not skilled in the art of RPKI, so perhaps I lack imagination, but I'm not understanding why these two SHOULDs aren't MUSTs. I'm not asking for a change, but if the document included explanations of why an implementation might not do the SHOULDs, some readers might thank you. The RP SHOULD add all publish elements to a local storage and update its last processed serial number to the serial number of this delta file. The RP SHOULD NOT remove objects from its local storage solely because it encounters a "withdraw" element, because this would enable a publication server to withdraw any object without the signing Certificate Authority consent. The RP could use additional strategies to determine if an object is still relevant for validation before removing it from its local storage. In particular objects should not be removed if they are included in a current validated manifest.
- [sidr] Spencer Dawkins' No Objection on draft-iet… Spencer Dawkins
- Re: [sidr] Spencer Dawkins' No Objection on draft… Tim Bruijnzeels
- Re: [sidr] Spencer Dawkins' No Objection on draft… Oleg Muravskiy
- Re: [sidr] Spencer Dawkins' No Objection on draft… Spencer Dawkins at IETF