Re: [Sidrops] Interim Meeting Follow-up Mail

Tim Bruijnzeels <tim@nlnetlabs.nl> Fri, 30 October 2020 12:52 UTC

Return-Path: <tim@nlnetlabs.nl>
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 C78E23A0E6F for <sidrops@ietfa.amsl.com>; Fri, 30 Oct 2020 05:52:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl
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 saLQzcGUG5QK for <sidrops@ietfa.amsl.com>; Fri, 30 Oct 2020 05:52:53 -0700 (PDT)
Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78C93A0E6D for <sidrops@ietf.org>; Fri, 30 Oct 2020 05:52:52 -0700 (PDT)
Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 404F2607C6; Fri, 30 Oct 2020 12:52:50 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1604062369; bh=/esGLPUQ1V3uBv/rLGDqjDleNHFfuAtizZ2FPG5n/Dk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=X756cceE5bayCZQQpjR6znycnQKclVwwrrTGcb2mHtiSnj40i55i2puuEey4Z4okP FThwfVUS6iRY2piau5u73JwD4xzmDckk/SXkB2vuY2TDWLcuKn8teZ9b4gEQWLufsG GOB/AZb4ICDMnj6eIbyXLVkIjit7nd9GQ1ztXs/2J9wf9GD3Lejds9g0Sp6dl5B6ys xZUwCYVbAU8Cy2Z/2hPWckxVqW/vxE+ZAddr95izefXzupbFIwWPJcLN4P2otArGz9 pAjh0lNMzWAPKWJoPP4ajEOmM7tsO2k4fgJfpcBkqvM+H3WcIzs2MXjVl+SvYEQ4nF wV9rPE10L38Nw==
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <e96b8e00-299e-dca3-0d06-b650925303d2@verizon.net>
Date: Fri, 30 Oct 2020 13:52:48 +0100
Cc: sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <92BBA00D-0BE1-4161-AB93-0E82EFF2E999@nlnetlabs.nl>
References: <87zh4ekvz9.wl-morrowc@ops-netman.net> <5660E325-98A9-4A3F-A009-BD13A5C62A47@nlnetlabs.nl> <06995a21-7cc8-1182-0472-00105ac7dd6d@verizon.net> <4A518084-54AB-4719-A9CD-11DD8AA9E63D@nlnetlabs.nl> <bad467c3-3fc5-d971-bc5b-cfe35fe5cd70@verizon.net> <72E7C44B-7478-402B-A0F3-2376A2818657@nlnetlabs.nl> <e96b8e00-299e-dca3-0d06-b650925303d2@verizon.net>
To: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/MKeEnLDOpohGpJcfutgZ0gforEI>
Subject: Re: [Sidrops] Interim Meeting Follow-up Mail
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: Fri, 30 Oct 2020 12:52:55 -0000

Hi Steve,

Thank you. That text works for me.

Tim

> On 29 Oct 2020, at 16:37, Stephen Kent <stkent=40verizon.net@dmarc.ietf.org> wrote:
> 
> Tim,
> 
> I revised the text of 6.4 and 6.7 to address the issues you cited. See below:
> 
> 6.4.  Acquiring Files Referenced by a Manifest
>  
>    The RP MUST acquire all of the files enumerated in the manifest
>    (fileList) from the publication point. If there are files listed in
>    the manifest that cannot be retrieved from the publication point, or
>    if they fail the validity tests specified in [RFC6488], the fetch has
>    failed and the RP MUST proceed to Section 6.7; otherwise, proceed to
>    Section 6.5. Note that all RPs MUST be able to process Manifests, 
>    CRLs and Resource Certificates [RFC6487], BGPsec Router Certificates
>    {RFC8209], Ghostbuster Records [RFC6493], and ROAs [RFC6482]. The
>    set of retrieved objects may include other RPKI object types that the 
>    RP is not prepared to process. When such objects are encountered by an
>    RP, the RP MUST NOT attempt to validate the eContent (as described in
>    Section 2.1.3.2 above) of such objects; encountering such objects does
>    not, per se, result in a failed fetch.
> 
> 
> 6.7.  Failed Fetches
>  
>    If a fetch fails for any of the reasons cited in 6.2-6.6, the RP MUST 
>    issue a warning indicating the reason(s)for termination of processing
>    with regard to this CA instance.  It is RECOMMENDED that a human 
>    operator be notified of this warning.
>  
>    Termination of processing means that the RP SHOULD continue to use
>    cached versions of the objects associated with this CA instance,
>    until such time as they become stale or they can be replaced by
>    objects from a successful fetch.  This implies that the RP MUST not
>    try to acquire and validate subordinate signed objects, e.g.,
>    subordinate CA certificates, until the next interval when the RP is
>    scheduled to fetch and process data for this CA instance.
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops