IETF Logo Mail Archive

Re: [sidr] posted: draft-huston-sidr-validity-00.txt

Geoff Huston <gih@apnic.net> Thu, 15 October 2015 22:21 UTC

Return-Path: <gih@apnic.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6261A8034 for <sidr@ietfa.amsl.com>; Thu, 15 Oct 2015 15:21:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.801
X-Spam-Level:
X-Spam-Status: No, score=-101.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=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 lK03Qza8ehPJ for <sidr@ietfa.amsl.com>; Thu, 15 Oct 2015 15:21:40 -0700 (PDT)
Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (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 D729F1A86F6 for <sidr@ietf.org>; Thu, 15 Oct 2015 15:21:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=d5DInGqCfOo7JCVVzV4luGf9y5kOde+fqpsqyTwL8II=; b=NhokioyJeOcQFealn91Cz3qpYA7Brt8H7lVPnRQiiGyOmPr44hIMqK3U/1Lz+6ngUWrkV8pf6rc8E P6PsS1guv1dsqrCZBMGpgvY6P+D/4jl9vRUhmBzI7hRbtJrTUuu5gQB2d3M2jo0oM7Q2/DFKwIjaP6 ZW3WEYj2+4+rcRoE=
Received: from NXMDA2.org.apnic.net (unknown [IPv6:2001:dd8:9:2::101:249]) by nx-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS for <sidr@ietf.org>; Fri, 16 Oct 2015 08:22:19 +1000 (AEST)
Received: from dhcp150.potaroo.net (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.1.218.12; Fri, 16 Oct 2015 08:23:40 +1000
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Geoff Huston <gih@apnic.net>
In-Reply-To: <alpine.LRH.2.03.1510131517100.32318@tislabs.com>
Date: Fri, 16 Oct 2015 09:21:36 +1100
Content-Transfer-Encoding: quoted-printable
Message-ID: <0719A207-9171-4023-9BE9-0D62A39AE957@apnic.net>
References: <alpine.LRH.2.03.1510131517100.32318@tislabs.com>
To: sidr wg list <sidr@ietf.org>
X-Mailer: Apple Mail (2.3094)
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/CsvjcgcYz-7Wzg0iCAJ6mW0XReI>
Subject: Re: [sidr] posted: draft-huston-sidr-validity-00.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
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, 15 Oct 2015 22:21:42 -0000

> On 15 Oct 2015, at 2:02 AM, Samuel Weiler <weiler@tislabs.com> wrote:
> 
>> We were about to ask the WG chairs for a WG Last Call on this document, but then noticed that this is an informational document and its attempting to update a standards track RFC
> 
> Changing the "intended status" of a doc seems easier than spinning a new one.  In any case, I would prefer to see the change and the context for it kept together.
> 
> Also, both/either document would benefit from a more meaningful abstract and intro.  At the very least, briefly explain _what_ is being changed. (The abstract and intro of the current WG doc hint at "why", but still don't say "what".  The new doc does neither.)
> 


“The new doc does neither” 

You are joking - right?

Lets see - the Abstract states:

  "This document updates the RPKI certificate validation procedure as specified in Section 7.2 of RFC6487."

And the introduction states:

  "This document updates the RPKI certificate validation procedure as specified in Section 7.2 of [RFC6487], by replacing the section 7.2 of [RFC6487] with the specification contained here.”

I believe that this is a very clear, concise and accurate description of WHAT is being changed. i.e. go look up section 7.2 of RFC6487 and replace it with the procedure described in this document. What exactly gives you a problem with such a explanation of the proposed update to the RPKI validation procedure?

Geoff

v2.23.0 | Report a Bug | By Email