[SPKM] Interoperability

Sam Hartman <hartmans-ietf@mit.edu> Tue, 31 October 2006 19:24 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GezDX-00040O-2I; Tue, 31 Oct 2006 14:24:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GezDU-00040I-OT for spkm@ietf.org; Tue, 31 Oct 2006 14:24:08 -0500
Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GezDQ-0000Kw-Gm for spkm@ietf.org; Tue, 31 Oct 2006 14:24:08 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 303B6E0035; Tue, 31 Oct 2006 14:23:50 -0500 (EST)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: spkm@ietf.org
Date: Tue, 31 Oct 2006 14:23:50 -0500
Message-ID: <tsl4ptkthkp.fsf@cz.mit.edu>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Subject: [SPKM] Interoperability
X-BeenThere: spkm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Low Infrastructure Public Key GSS mechanism <spkm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/spkm>, <mailto:spkm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/spkm>
List-Post: <mailto:spkm@ietf.org>
List-Help: <mailto:spkm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/spkm>, <mailto:spkm-request@ietf.org?subject=subscribe>
Errors-To: spkm-bounces@ietf.org


Hi.


I think one of the most important outcomes of the BOF is likely to be
an understanding of what level of interoperability is required between
the existing SPKM RFC and our solution to the NFS V4 problem and what
pressures there are to minimize change to the spec.

First, if we break interoperability, we're changing the OID.  If we're
not sure we're maintaining interoperability we're changing the OID.
RPC supports a mechanism for advertizing GSS mechanisms and so the
cost of changing the OID is relatively low.  Servers and clients that
want to implement both mechanisms can do so.

Here are some questions to think about:


* What deployed production code is out there that either interoperates
  with the RFC or draft-adamson?

* Can we meet our security and other requirements without making
  backward incompatible changes and forcing an OID change?

* Going forward, can we obtain a simpler spec or implementation by
  making non-backward compatible changes?


* When will we get a spec out?  How long will the market wait?
  Sometimes, you have to accept that the market will deploy something
  and you have little influence on it.  In those cases it's better to
  write a compelling spec and hope that people will migrate.  Other
  times, if you can stretch to meet market timing, you can avoid the
  market deploying something that does not meet your spec.  That is
  very desirable.


* Which will take longer: fixing this spec or starting from scratch?

--Sam

_______________________________________________
SPKM mailing list
SPKM@ietf.org
https://www1.ietf.org/mailman/listinfo/spkm