The proper fole of version numbers

[Dave Crocker-2]

Folks,

Howdy.

Some specifications embed a version number in the protocol or format data.  Most
IETF protocols do not.

Over the years, I've come to believe that the lesson to us has been that version
numbers really aren't all that helpful and that the proper way to distinguish
truly incompatible versions is through use of a different value in the
underlying multiplexing field.  So, different IP <protocol> field, different
<port> number, different DNS underscore "attribute", etc.

As a recent, private discussion has progressed, I've started to consider the
topic more interesting than I had previously thought and wondered whether there
was interest amongst others to pursue it?

d/

--

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
http://www.ietf.org/mailman/listinfo/architecture-discuss

[John Day-2]

After years of looking at the problem and first realizing that
protocol id field couldn't identify the protocol in the layer above,
I concluded it was identifying the syntax of the protocol in the
layer above.  However further consideration determined that that was
not so much wrong but the wrong direction.  I finally came to the
conclusion that:

Any requirement for a protocol id field is an indication of either
the layer boundary being in the wrong place or a poorly designed
layer.  Protocol id fields are unnecessary.

If you need one, you have done something wrong somewhere else. Go
back and re-work it.

Take care,
John

At 9:13 -0800 2008/02/06, Dave Crocker wrote:

>Folks,
>
>Howdy.
>
>Some specifications embed a version number in the protocol or format
>data.  Most
>IETF protocols do not.
>
>Over the years, I've come to believe that the lesson to us has been
>that version
>numbers really aren't all that helpful and that the proper way to distinguish
>truly incompatible versions is through use of a different value in the
>underlying multiplexing field.  So, different IP <protocol> field, different
><port> number, different DNS underscore "attribute", etc.
>
>As a recent, private discussion has progressed, I've started to consider the
>topic more interesting than I had previously thought and wondered
>whether there
>was interest amongst others to pursue it?
>
>d/
>
>--
>
>    Dave Crocker
>    Brandenburg InternetWorking
>    bbiw.net
>_______________________________________________
>Architecture-discuss mailing list
>Architecture-discuss@...
>http://www.ietf.org/mailman/listinfo/architecture-discuss

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
http://www.ietf.org/mailman/listinfo/architecture-discuss

[Joe Touch]

Quoting Dave Crocker <dhc@...>:

> Folks,
>
> Howdy.
>
> Some specifications embed a version number in the protocol or format data.
> Most IETF protocols do not.

I noted this when a blanket request for "lessons learned" went out.

> Over the years, I've come to believe that the lesson to us has been that
> version numbers really aren't all that helpful and that the proper
> way to distinguish truly incompatible versions is through use of a
> different value in the  underlying multiplexing field.
>  So, different IP <protocol> field, different
> <port> number, different DNS underscore "attribute", etc.

I'd like to understand this more. There are two muxing fields - one defined in
the higher level (e.g., Ethernet frames), and one inside the protocol (e.g., IP
version). The pair <eth_proto><ip_ver> is the overall demuxing; the key
question is whether ethernet needs to demux IPv4 differently from IPv6 (FWIW,
it currently does, rendering the IP version field moot for
ethernet-encapsulated frames).

IMO, versioning is the responsibility of the protocol itself, not the parent
protocol. Version changes are defined and should thus be contained entirely
within a protocol. It doesn't make sense to consume shared demux space at the
outer layer protocol to handle problems created by only a subset of protocols.


The cost of putting the version field inside the protocol itself is the cost of
pinning the first bits of header, and often also then requires the chunksize
(8, 16, 32, ... bits), bit, and word order to be fixed through at least the
version area. I don't consider this a big issue; if a protocol changes word
order, then it can be issued a new higher-level <proto> number.

IMO, the two (<proto><vers>) should be considered major/minor revision numbers.
There are cases where it is appropriate to increment either; I don't see a
great argument to force all increments to occur in either side of that overall
field, though I prefer to err on the "keep your mess to yourself" position that
says "think twice before incrementing <proto>, then don't unless there's no
other way".

> As a recent, private discussion has progressed, I've started to consider the
> topic more interesting than I had previously thought and wondered whether
> there was interest amongst others to pursue it?

Count me in, obviously...

Joe
_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
http://www.ietf.org/mailman/listinfo/architecture-discuss

[Joel M. Halpern-3]

This is something I have debated in quite a few contexts.
It seems to me that there are a range of needs, and that a version
number can be useful for a specific subset of that range.  People
frequently tend to treat it much too broadly.

I will start however with a caveat.  While the following theoretical
perspective seems to suggest significant value for a version number, and
I frequently try to design one in for these needs, I note that there are
few or no places where it has actually been both needed and effective.
So the following may be a classic case of something that looks good in
theory, but not in practice.

With most of the protocols we design, we use a core basic mechanism, and
then some form of extension or addition.  We hope and try to get it
right that the extension mechanisms will be sufficient for what we need.
However, it seems sensible to also design for needing to change the
basic mechanism (the mandatory fields in the basic message header, or
similar core items.)  If one wants to deploy such a change, the ability
to negotiate which basic header one is using, or at least to confirm
compatibility of that basic header, seems very useful.
Even if one is not negotiating, the ability to support more than one
variation, and to use the one that the other party supports, is
conceptually powerful.
This seems to work better in pairwise protocols with an opening
negotiation (such as BGP or PNNI) than in protocols for more dynamic
communication establishment (such as IP or SIP)

Yours,
Joel

Dave Crocker wrote:

> Folks,
>
> Howdy.
>
> Some specifications embed a version number in the protocol or format data.  Most
> IETF protocols do not.
>
> Over the years, I've come to believe that the lesson to us has been that version
> numbers really aren't all that helpful and that the proper way to distinguish
> truly incompatible versions is through use of a different value in the
> underlying multiplexing field.  So, different IP <protocol> field, different
> <port> number, different DNS underscore "attribute", etc.
>
> As a recent, private discussion has progressed, I've started to consider the
> topic more interesting than I had previously thought and wondered whether there
> was interest amongst others to pursue it?
>
> d/
>

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
http://www.ietf.org/mailman/listinfo/architecture-discuss

[distobj]

On 2/6/08, Dave Crocker <dhc@...> wrote:

> Folks,
>
> Howdy.
>
> Some specifications embed a version number in the protocol or format data.  Most
> IETF protocols do not.
>
> Over the years, I've come to believe that the lesson to us has been that version
> numbers really aren't all that helpful and that the proper way to distinguish
> truly incompatible versions is through use of a different value in the
> underlying multiplexing field.  So, different IP <protocol> field, different
> <port> number, different DNS underscore "attribute", etc.

I think there's a place for both approaches, but I do agree that the
encapsulating layer mux/dispatch-point isn't used as often as it
should be.

> As a recent, private discussion has progressed, I've started to consider the
> topic more interesting than I had previously thought and wondered whether there
> was interest amongst others to pursue it?

A BCP for protocol versioning sounds like a good idea.

FWIW, at the top of the protocol stack is data versioning, which the
W3C TAG (BCCd, because I'm sure they'd be interested) has been
exploring;

http://www.w3.org/2001/tag/doc/versioning

Mark.
--
Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com
_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
http://www.ietf.org/mailman/listinfo/architecture-discuss

[Brian E Carpenter-2]

I'd be grateful if people interested in this question would
have a look at
http://tools.ietf.org/id/draft-carpenter-extension-recs-02.txt
and say whether
(a) it's worth resuming work on it
(b) what it has to say about versioning makes sense.

fwiw I think the abstract value of version numbers depends very
much on whether the versioning handles backwards compatibility
or not. If you break compatibility, the version number
effectively says "this is a new protocol." But since
protocol numbers and assigned ports are finite resources,
maybe that's what we have to do.

   Brian


On 2008-02-07 06:13, Dave Crocker wrote:

> Folks,
>
> Howdy.
>
> Some specifications embed a version number in the protocol or format data.  Most
> IETF protocols do not.
>
> Over the years, I've come to believe that the lesson to us has been that version
> numbers really aren't all that helpful and that the proper way to distinguish
> truly incompatible versions is through use of a different value in the
> underlying multiplexing field.  So, different IP <protocol> field, different
> <port> number, different DNS underscore "attribute", etc.
>
> As a recent, private discussion has progressed, I've started to consider the
> topic more interesting than I had previously thought and wondered whether there
> was interest amongst others to pursue it?
>
> d/
>

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
http://www.ietf.org/mailman/listinfo/architecture-discuss

[Tony Li-4]

On Feb 6, 2008, at 10:57 AM, Joel M. Halpern wrote:

> I will start however with a caveat.  While the following theoretical
> perspective seems to suggest significant value for a version  
> number, and
> I frequently try to design one in for these needs, I note that  
> there are
> few or no places where it has actually been both needed and effective.
> So the following may be a classic case of something that looks good in
> theory, but not in practice.
>
> With most of the protocols we design, we use a core basic  
> mechanism, and
> then some form of extension or addition.  We hope and try to get it
> right that the extension mechanisms will be sufficient for what we  
> need.
> However, it seems sensible to also design for needing to change the
> basic mechanism (the mandatory fields in the basic message header, or
> similar core items.)  If one wants to deploy such a change, the  
> ability
> to negotiate which basic header one is using, or at least to confirm
> compatibility of that basic header, seems very useful.
> Even if one is not negotiating, the ability to support more than one
> variation, and to use the one that the other party supports, is
> conceptually powerful.
> This seems to work better in pairwise protocols with an opening
> negotiation (such as BGP or PNNI) than in protocols for more dynamic
> communication establishment (such as IP or SIP)

I'll have to largely agree with this.  In my experience, encoding  
first for extensibility is a requirement (e.g., TLVs).  Once you've  
done this, you've necessarily made some design choices that involve  
finite fields (e.g., how many type codes do you have?).  Having a  
version number elsewhere in the packet is some cheap insurance  
against running out of type codes or making the type field much  
larger than would seem optimal.  The same reasoning would seem to  
apply to avoiding issues of an inadequate or oversized length field.  
A version number also allows you to make other changes to the fixed  
header in the message,

Tony

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
http://www.ietf.org/mailman/listinfo/architecture-discuss

[John Day-2]

I would have to agree with Tony and Joel on version number fields.
They seem better in theory than useful in practice. Probably a waste
of time.  Better to simply design the protocol to be extensible.  But
from what I have seen of the modern class of protocols, extensibility
is essentially the degenerate case.

Version numbers were interesting 20 years ago, but not now.  And as
Joel indicated, even then it looked better in theory than it turned
out in practice.

Take care,



At 14:09 -0800 2008/02/06, Tony Li wrote:

>On Feb 6, 2008, at 10:57 AM, Joel M. Halpern wrote:
>
>>  I will start however with a caveat.  While the following theoretical
>>  perspective seems to suggest significant value for a version
>>  number, and
>>  I frequently try to design one in for these needs, I note that
>>  there are
>>  few or no places where it has actually been both needed and effective.
>>  So the following may be a classic case of something that looks good in
>>  theory, but not in practice.
>>
>>  With most of the protocols we design, we use a core basic
>>  mechanism, and
>>  then some form of extension or addition.  We hope and try to get it
>>  right that the extension mechanisms will be sufficient for what we
>>  need.
>>  However, it seems sensible to also design for needing to change the
>>  basic mechanism (the mandatory fields in the basic message header, or
>>  similar core items.)  If one wants to deploy such a change, the
>>  ability
>>  to negotiate which basic header one is using, or at least to confirm
>>  compatibility of that basic header, seems very useful.
>>  Even if one is not negotiating, the ability to support more than one
>>  variation, and to use the one that the other party supports, is
>>  conceptually powerful.
>>  This seems to work better in pairwise protocols with an opening
>>  negotiation (such as BGP or PNNI) than in protocols for more dynamic
>>  communication establishment (such as IP or SIP)
>
>
>I'll have to largely agree with this.  In my experience, encoding
>first for extensibility is a requirement (e.g., TLVs).  Once you've
>done this, you've necessarily made some design choices that involve
>finite fields (e.g., how many type codes do you have?).  Having a
>version number elsewhere in the packet is some cheap insurance
>against running out of type codes or making the type field much
>larger than would seem optimal.  The same reasoning would seem to
>apply to avoiding issues of an inadequate or oversized length field.  
>A version number also allows you to make other changes to the fixed
>header in the message,
>
>Tony
>
>_______________________________________________
>Architecture-discuss mailing list
>Architecture-discuss@...
>http://www.ietf.org/mailman/listinfo/architecture-discuss

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
http://www.ietf.org/mailman/listinfo/architecture-discuss

[tom.petch-2]

I suspect that it depends on where you are sitting in software development
process.

If you introduce a new version number, then the software for the old version
number must be updated to demux the new version to the appropriate handler.

If you use the SAP of the underlying protocol, then your software can continue
unaltered, but the software of the underlying protocol must be updated to demux
to something else.

But if you are a user, who looks at protocol decodes to determine why a network
is not working as it should, then having the information all in one place, a
version number in the protocol header is always to be preferred, as 'helpful'
protocol decoders have a habit of stripping off the lower, 'less interesting'
layers.

I think that SNMP, retaining the header format and updating the version number,
gets it absolutely right.

Tom Petch

----- Original Message -----
From: <touch@...>
To: <dcrocker@...>; "Dave Crocker" <dhc@...>
Cc: <architecture-discuss@...>
Sent: Wednesday, February 06, 2008 6:44 PM
Subject: Re: [arch-d] The proper fole of version numbers

> Quoting Dave Crocker <dhc@...>:
>
> > Folks,
> >
> > Howdy.
> >
> > Some specifications embed a version number in the protocol or format data.
> > Most IETF protocols do not.
>
> I noted this when a blanket request for "lessons learned" went out.
>
> > Over the years, I've come to believe that the lesson to us has been that
> > version numbers really aren't all that helpful and that the proper
> > way to distinguish truly incompatible versions is through use of a
> > different value in the  underlying multiplexing field.
> >  So, different IP <protocol> field, different
> > <port> number, different DNS underscore "attribute", etc.
>
> I'd like to understand this more. There are two muxing fields - one defined in
> the higher level (e.g., Ethernet frames), and one inside the protocol (e.g.,

IP

> version). The pair <eth_proto><ip_ver> is the overall demuxing; the key
> question is whether ethernet needs to demux IPv4 differently from IPv6 (FWIW,
> it currently does, rendering the IP version field moot for
> ethernet-encapsulated frames).
>
> IMO, versioning is the responsibility of the protocol itself, not the parent
> protocol. Version changes are defined and should thus be contained entirely
> within a protocol. It doesn't make sense to consume shared demux space at the
> outer layer protocol to handle problems created by only a subset of protocols.
>
>
> The cost of putting the version field inside the protocol itself is the cost

of
> pinning the first bits of header, and often also then requires the chunksize
> (8, 16, 32, ... bits), bit, and word order to be fixed through at least the
> version area. I don't consider this a big issue; if a protocol changes word
> order, then it can be issued a new higher-level <proto> number.
>
> IMO, the two (<proto><vers>) should be considered major/minor revision
numbers.
> There are cases where it is appropriate to increment either; I don't see a
> great argument to force all increments to occur in either side of that overall
> field, though I prefer to err on the "keep your mess to yourself" position
that

> says "think twice before incrementing <proto>, then don't unless there's no
> other way".
>
> > As a recent, private discussion has progressed, I've started to consider the
> > topic more interesting than I had previously thought and wondered whether
> > there was interest amongst others to pursue it?
>
> Count me in, obviously...
>
> Joe
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@...
> http://www.ietf.org/mailman/listinfo/architecture-discuss

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
http://www.ietf.org/mailman/listinfo/architecture-discuss