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

"Mirja Kuehlewind" <ietf@kuehlewind.net> Wed, 15 February 2017 16:06 UTC

Return-Path: <ietf@kuehlewind.net>
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 82BC2129647; Wed, 15 Feb 2017 08:06:17 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "Mirja Kuehlewind" <ietf@kuehlewind.net>
To: "The IESG" <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.43.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148717477752.17305.14232510120804304925.idtracker@ietfa.amsl.com>
Date: Wed, 15 Feb 2017 08:06:17 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/VPacK4EYuGt-KqCWZdQpPpvYjEA>
Cc: morrowc@ops-netman.net, sidr-chairs@ietf.org, draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, sidr@ietf.org
Subject: [sidr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-s?= =?utf-8?q?idr-rpki-rtr-rfc6810-bis-08=3A_=28with_DISCUSS=29?=
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: Wed, 15 Feb 2017 16:06:17 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: Discuss

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:


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 ignor
unknown types which is exactl what you want. There in this case I don't
see that a new version necessary. 

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. 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.