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

[Rob Austein <[e-mail]>]

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.