Re: [sidr] Mirja Kühlewind's Discuss on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with DISCUSS)

Rob Austein <sra@hactrn.net> Wed, 15 February 2017 16:26 UTC

Return-Path: <sra@hactrn.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 A504B1298C1; Wed, 15 Feb 2017 08:26:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 CfMwj7RwrCDe; Wed, 15 Feb 2017 08:26:14 -0800 (PST)
Received: from khatovar.hactrn.net (khatovar.hactrn.net [198.180.150.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3F2129661; Wed, 15 Feb 2017 08:26:14 -0800 (PST)
Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id C1BD61398E; Wed, 15 Feb 2017 16:26:12 +0000 (UTC)
Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 5C79447A4F05; Wed, 15 Feb 2017 11:26:11 -0500 (EST)
Date: Wed, 15 Feb 2017 11:26:11 -0500
From: Rob Austein <sra@hactrn.net>
To: "Mirja Kuehlewind" <ietf@kuehlewind.net>
In-Reply-To: <148717477752.17305.14232510120804304925.idtracker@ietfa.amsl.com>
References: <148717477752.17305.14232510120804304925.idtracker@ietfa.amsl.com>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20170215162611.5C79447A4F05@minas-ithil.hactrn.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/6g4_5UP2pKeLVwaDTwv65BUZIq0>
Cc: draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, Chris Morrow <morrowc@ops-netman.net>, sidr-chairs@ietf.org, The IESG <iesg@ietf.org>, sidr@ietf.org
Subject: Re: [sidr] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ietf?= =?iso-8859-1?q?-sidr-rpki-rtr-rfc6810-bis-08=3A_=28with_DISCUSS=29?=
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: Wed, 15 Feb 2017 16:26:15 -0000

At Wed, 15 Feb 2017 08:06:17 -0800, Mirja Kuehlewind wrote:
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> This is a general discuss on the principle of using extension mechanisms
> (like versioning) and how and when to use it.
> 
> This document increases the version number to add one new PDU type as
> well as to clarify some questions on timing parameters. However,
> versioning is just one extensibility mechanism out-of a whole set of
> option. In this case the protocol also has an (8 bit) type field to
> define new PDU types. Only 8 types are used so far (in version 0 of the
> protocol) out of 2^8 which leaves another option for extending the
> protocol. The usually specification here is that the receiver will ignore
> unknown types which is exactl what you want. There in this case I don't
> see that a new version necessary. 

The format of the End Of Data PDU also changed.

> Further there is an issue on how the versioning is done. This document
> looks like a bis document and used to obsolete the old spec till the last
> version (-07) but now neither updates nor obsolete it.

Correct.  Our AD told us that we could not both obsolete version zero
and specify how to fall back from version one to version zero.  Please
feel free to take this up with our AD.

> If you actually decide to have a new version, that might be right
> (also updating might be an option which I would actually recommend
> in this case because I believe the expectation is that new
> implementation should always implement this version) but I don't
> really see in this case that doublicating all the text is the best
> option.
> 
> I would actually not recommend to increase the version because I really
> don't see a need for this, given the (much easier) extensibily mechanism
> you have with the type. If you'd only would like add the new type, then
> actually a short draft that defines the type and updates rfc6810 would be
> sufficient. Regarding the other calrification, I think this could also be
> done in a short (potentially the same) updating draft. If you still think
> it better to copy all the text and have one clean draft than obsoleting
> is the right choice.