Subject: Re: TSP version 03

From: "David P. Kemp" <[email-masked]>
Date: Thu, 23 Sep 1999 09:55:46 -0400 (EDT)

John,

A comment on item ii):  an explicit version number field is
the traditional means of allowing a protocol engine to determine that
it does not understand a PDU from a later version of the protocol,
but it is not a particularly good or useful means.

1) The presence or absence of a version number is immaterial to the
ability to accommodate future changes.  If a v1 engine encounters a PDU
with an explicit version number of v2, what can it do other than say
"I don't understand".  How is this different from omitting the version
number and including v2 data that is not legal in v1 of the protocol -
the engine still says "I don't understand", and can still take action
identical to what it would have taken upon encountering an unrecognized
explicit version number.

2) If a particular data item is legal in both v1 and v2, but the
semantics of the datum are affected by the version number, then I
would say the v2 protocol design is botched.

3) A version number offers no guidance on where the protocol may be
extended in the future (i.e. items may be added to this list, values
may be added to this enumeration, the legal range of this item may be
extended, etc).  A version number offers no guidance on what action
should be taken when encountering data from a future version.

In short, saying "add an explicit version number field" to allow for
future changes is both easy and ineffective.  A harder but better
suggestion would be to define where the protocol might be extended
in the future and what should be done on encountering data from
beyond the supported version.

Dave Kemp

Note: I take no credit for the above - it is taken wholesale from
Prof. Larmouth's discussion of extensibility and exceptions in
"ASN.1 Complete".

> From: [email-masked]
> Subject: Re: TSP version 03
> To: Denis Pinkas <[email-masked]>
> Cc: IETF-PXIX <[email-masked]>
> 
> Denis,
> 
> The TSP-over-TCP protocol defined in the new draft suffers from some of the
> same problems we found in the CMP-over-TCP protocol in RFC 2510.  I would
> suggest that the changes recommended in the new
> draft-ietf-pkix-cmp-tcp-00.txt be applied to TSP-over-TCP as well.  These
> changes include:
> 
> i)  Changing the "poll time" from an absolute time to a delta time.  This
> is more robust than an absolute time in the event of a clock-skew between
> requester and responder, and also doesn't suffer from the Y2038 problem.
> 
> ii) Changing the protocol to contain an explicit version number field to
> allow for future changes.
> 
> iii) Specifying whether the TCP connection may remain up to carry multiple
> TSP requests, and which end is responsible for closing it.
> 
> John

---

From: Paul Koning <[email-masked]>
Date: Thu, 23 Sep 1999 11:30:21 -0400

Version numbers appear in many protocols, but not all use them the
right way.  Or the optimal way, if you prefer.

There are various protocols, especially old ones, that aren't directly 
extensible.  There you need a version number, which is incremented
whenever the packet format changes.

Extensible protocols, which basically means protocols that use tagged
fields (ASN.1, IPv4 options, etc.), don't have that strong a need for
version numbers.  At least not if the rules for handling tags are done 
right.  (Some are not; there are protocols that require you to reject
anything you don't recognize, which obviously blows the whole thing
right out of the water.  Fortunately they are rare.)  If you obey the
"be strict in what you send, lenient in what you receive" principle,
adding new tags to an existing protocol handles many new requirements.

If you do that, then you should NOT increment the version number.  In
other words, version number should identify a set of parsing rules,
not a specific set of tag values used.  If you add 100 new tags but
the rules for interpreting messages are unchanged, then the version
number shouldn't change.  (Certainly the major version should not.)
With tagged protocols, you only need change the (major) version number 
if you do something to the protocol that invalidates the parsing
rules.  For example, if tags change from one byte to two.

One useful thing some protocols have is a "critical" flag ("if you
don't understand this tag, reject the whole packet").  ATM's routing
protocol PNNI goes further, though it's not clear to me whether that
additional complexity will ever be used.

	paul

---

From: Ronald Tschal�r <[email-masked]>
Date: Thu, 23 Sep 1999 13:29:11 -0700 (PDT)

> identical to what it would have taken upon encountering an unrecognized

There is a serious difference between being able to detect a version
mismatch and trying to parse the packet using the wrong version. In
the first case I send back a useful error message, in the second case
I can't. The client, upon receiving a version mismatch error, can then
back down and use an older version (the new CMP-over-TCP protocol
specifies an error message containing the highest version the server
supports).

> would say the v2 protocol design is botched.

Agreed.

> should be taken when encountering data from a future version.

If it doesn't, then the protocol is botched. A version number only makes
sense if you nail down what to do when new versions are introduced. The
CMP-over-TCP protocol does exactly that. Please have a closer look at it
before you summarily dismiss version numbers.

Note that a network protocol is quite different from, say, an X.509
certificate. The network allows you to back down and retry using a
different version. Processing a fixed certificate which can't be
changed does not. So the version in a certificate should not be confused
with the version used in a network protocol.

  Cheers,

  Ronald