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

From: "Mirja Kuehlewind" <[email-masked]>
Date: Wed, 15 Feb 2017 08:06:17 -0800

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:
https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-rfc6810-bis/

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

---

From: Rob Austein <[email-masked]>
Date: Wed, 15 Feb 2017 11:26:11 -0500

At Wed, 15 Feb 2017 08:06:17 -0800, Mirja Kuehlewind wrote:
> protocol. The usually specification here is that the receiver will ignore

The format of the End Of Data PDU also changed.

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

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 15 Feb 2017 21:20:37 +0000

Thanks Rob!

Yes, initially this document was marked to obsolete rfc6810, but at the same time it mandated the use of the previous version as part of the Protocol Version Negotiation.  Given that it may take a while before caches and routers both implement this new version, we decided to settle on leaving rfc6810 alone for now, and declaring it Historic/Obsolete later on.

Alvaro.

On 2/15/17, 11:26 AM, "Rob Austein" <[email-masked]<mailto:[email-masked]>> wrote: