[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
- [SPKM] Interoperability Sam Hartman
- Re: [SPKM] Interoperability Nicolas Williams
- Re: [SPKM] Interoperability Nicolas Williams
- Re: [SPKM] Interoperability Sam Hartman
- Re: [SPKM] Interoperability Nicolas Williams
- Re: [SPKM] Interoperability Martin Rex
- Re: [SPKM] Interoperability Sam Hartman