Re: TSP version 03

["David P. Kemp" <[e-mail]>]

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: [e-mail]
> Subject: Re: TSP version 03
> To: Denis Pinkas <[e-mail]>
> Cc: IETF-PXIX <[e-mail]>
> 
> 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