IETF Logo Mail Archive

Re: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT)

Oleg Muravskiy <oleg@ripe.net> Thu, 16 February 2017 16:19 UTC

Return-Path: <oleg@ripe.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA52F1294B5; Thu, 16 Feb 2017 08:19:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
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 0QwrCLAYf6UK; Thu, 16 Feb 2017 08:19:48 -0800 (PST)
Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FCFB12949B; Thu, 16 Feb 2017 08:19:48 -0800 (PST)
Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <oleg@ripe.net>) id 1ceOmX-0009Gv-Ia; Thu, 16 Feb 2017 17:19:46 +0100
Received: from dog.ripe.net ([193.0.1.217] helo=[IPv6:::1]) by nene.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from <oleg@ripe.net>) id 1ceOmW-0002eJ-Dc; Thu, 16 Feb 2017 17:19:44 +0100
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset="utf-8"
From: Oleg Muravskiy <oleg@ripe.net>
In-Reply-To: <FFA004B6-F2F3-4389-9242-FB72756F097C@ripe.net>
Date: Thu, 16 Feb 2017 17:19:49 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <F1BE0BD7-699C-439E-9205-E22440ACCC7F@ripe.net>
References: <148722406650.31533.1672555654116871127.idtracker@ietfa.amsl.com> <FFA004B6-F2F3-4389-9242-FB72756F097C@ripe.net>
To: Tim Bruijnzeels <tim@ripe.net>
X-Mailer: Apple Mail (2.3124)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: ---------
X-RIPE-Spam-Report: Spam Total Points: -9.4 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b74eaab4746766417fce4b6a387fe00cb53
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/6Vbj5ey2lQnMG8g9rQGrmHENRUM>
Cc: morrowc@ops-netman.net, sidr chairs <sidr-chairs@ietf.org>, Spencer Dawkins <spencerdawkins.ietf@gmail.com>, sidr@ietf.org, draft-ietf-sidr-delta-protocol@ietf.org, The IESG <iesg@ietf.org>
Subject: Re: [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
Precedence: list
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 16:19:55 -0000

Hi Tim, all,

> On 16 Feb 2017, at 16:26, Tim Bruijnzeels <tim@ripe.net> wrote:
> 
> Hi Spencer, all,
> 
> On 16 Feb 2017, at 06:47, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:
>> 
>> ----------------------------------------------------------------------
>> 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.
> 
> corner cases: the RP already added this same object so strictly speaking it's1 already there, the object is 5TB in size? I don't think I can enumerate all corner cases, and believe the document should not try to go there.
> 
>> 
>>     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.
> 
> I can live with a "MUST NOT remove" here, but not sure that others agree.

I wouldn't go for MUST here, because, strictly speaking, there might not even be a local cache, it depends on how the validation is implemented.

We could either say "NOT RECOMMENDED ... if the local cache is used", or change this whole paragraph to a non-normative text, and possibly move it to Security Considerations.

And in this case the previous paragraph could change into "MUST update its last processed serial number", leaving the local cache out.


Oleg

v2.23.0 | Report a Bug | By Email