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

"Mirja Kuehlewind" <ietf@kuehlewind.net> Thu, 16 February 2017 15:15 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 235281293DF; Thu, 16 Feb 2017 07:15:56 -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: <148725815613.16000.13759828131194056664.idtracker@ietfa.amsl.com>
Date: Thu, 16 Feb 2017 07:15:56 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/miehPvEG5-jZ3Sen8ag8JWG5z9k>
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_No_Objection_on_draft-i?= =?utf-8?q?etf-sidr-rpki-rtr-rfc6810-bis-08=3A_=28with_COMMENT=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: Thu, 16 Feb 2017 15:15:56 -0000

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

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 document should update rfc6810 as discussed with responsible AD.

Here is my old discuss for the record:

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 exactly 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 duplicating 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) extensibility
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 clarification, 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.