Fw: RE: [LinkSec] scope
Forwarding this message from Mick Seaman.
The original message did not pass the filters due to the word inv_estment.
> From: "Mick Seaman" <mick_seaman@ieee.org>
> To: "'LinkSec'" <stds-802-linksec@ieee.org>
> Subject: RE: [LinkSec] scope
> Date: Tue, 29 Apr 2003 10:54:00 -0700
>
> Well of course we all hope wisdom and broad vision succeeds in all things
> (with no time penalty, the net present value of perfection at some
> undetermined future time being low).
>
> However I have to say that 20:20 foresight is rare and that extensibility
> often turns out not to have been provided in the direction that was
actually
> required with hindsight, but in fact in some other direction , not
actually
> required but only vaguely, wishfully conceived, and 'obvious', but
bringing
> in many complications. If something can't be fully worked out it has not
> been future proofed, but just complicated.
>
> There is a means of extension for all layer 2 protocols, it is called
> another Ethertype/protocol.
>
> A less wasteful extension, in some circumstances, is the protocol version,
> but that brings in the need for considerable foresight and discipline on
the
> behavior of current implementations to process future versions.
>
> So the question, I submit, is how any aspect of extensibility can be
> incorporated in any aspect of the protocol (let's take a secured packet
> format as a simple thought experiment, and much the easiest to get right)
> such that the following tests can be applied to the extensibility:
>
> (1) The design imposes no or miniscule implementation burden over a
possible
> substitute design which is not extensible, and as such is not prey to
being
> substituted out in favor of 'more efficient' proprietary protocols or
indeed
> completely different standard solutions.
>
> (2) The extension does not provide a number of options which can be
> conformantly selected in different ways by different vendors, such that
the
> standard becomes only a cloak for lack of vendor to vendor
interoperability.
>
> (3) The behavior of any conformant implementation in following the design
> does not differ in 'immediate' use from the behavior in 'future
extensible'
> use, and the fully range of behavior is exercised in current deployment,
or
>
> (4) The future use is tightly specified, and mechanisms are in place to
> ensure that all implementations will be both rigorously tested by the QA
> organizations of their developers and conformance test organizations
across
> the complete spectrum of potential use (as opposed to how they are going
to
> be used for the next few years in customers networks).
>
> If the last condition is not met all that will be achieved is the ability
of
> the standards group to say simply and smugly 'not our fault, we provided
> extensibility' when it turns out that the world has been populated with
> implementations that will work according to the realistic immediate goals
of
> the standard, but require any given network to have a 'flag day' on which
> all old implementations are removed before the new extensible
> implementations are deployed. This can actually be worse than deploying a
> new completely distinguished protocol to meet the new, and by then fully
> designed, extended objectives.
>
> There is of course another form of 'extensible' as applied to a standard.
> This means that the standard has been technically constructed to allow
> additions to be made to it over a period of many years by the originating
> group, rather than ceding the turf to any other group with a
> newer/broader/different scope. This form of extensibility is quite easy to
> arrange, but is a tax on rather than a benefit to the end user, since it
has
> no hurdles of future compatability to overcome, just vague promises of
> inv_estment protection. I hope we can recognize this error if we ever come
> close to it.
>
> Mick
>
>
>
>
> -----Original Message-----
> From: owner-stds-802-linksec@majordomo.ieee.org
> [mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of Rene
> Struik
> Sent: Monday, April 28, 2003 8:10 PM
> To: Russ Housley
> Cc: Dolors Sala; Mats Naslund; LinkSec
> Subject: [LinkSec] scope
>
>
>
> Dear all:
>
> The proper approach is to define a security conceptual blueprint that
allows
> for
> extensibility. Once this is done, one can care about the partitioning of
the
> security in things that are inside and those that are outside scope. As
far
> as
> extensibility goes, it is not so easy to extend single-hop scenarios to
> multi-hop ones if one has not given the latter proper consideration first;
> the
> other way around, however, is just a special case. I hope wisdom and a
> borader
> vision will prevail.
>
> Rene
>
>
>
>