Re: [SPKM] Interoperability

Sam Hartman <hartmans-ietf@mit.edu> Fri, 03 November 2006 22:28 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg7WW-0005Ij-Uy; Fri, 03 Nov 2006 17:28:28 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg7VW-0003rR-Sv for spkm@ietf.org; Fri, 03 Nov 2006 17:27:26 -0500
Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg7Ut-00048y-41 for spkm@ietf.org; Fri, 03 Nov 2006 17:26:48 -0500
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id EF63EE0035; Fri, 3 Nov 2006 17:26:35 -0500 (EST)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: martin.rex@sap.com
Subject: Re: [SPKM] Interoperability
References: <200611031936.UAA16703@uw1048.wdf.sap.corp>
Date: Fri, 03 Nov 2006 17:26:35 -0500
In-Reply-To: <200611031936.UAA16703@uw1048.wdf.sap.corp> (Martin Rex's message of "Fri, 3 Nov 2006 20:36:19 +0100 (MET)")
Message-ID: <tslfyd0b204.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.1 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: spkm@ietf.org
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

>>>>> "Martin" == Martin Rex <martin.rex@sap.com> writes:

    Martin> Nicolas Williams wrote:
    >> 
    >> On Tue, Oct 31, 2006 at 02:23:50PM -0500, Sam Hartman wrote:
    >> > * 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.
    >> 
    >> If we cannot get a spec that will meet our needs in time for
    >> the market then the proposed protocol could go to Informational
    >> and a spec that does meet our needs can later go to
    >> Proposed-Standard, using a different OID.

    Martin> There is a problem in the traditional (simple) GSS-API and
    Martin> how it is embedded within several application protocols,
    Martin> that there is no negotiation of a mechanism (OID).  In
    Martin> real distributed environments, where a component is both,
    Martin> server and client, a switch to a new OID might require a
    Martin> "flag day".  

This BOF at least is has a primary goal of trying to solve the problem
for NFS which does have a negotiation mechanism.

We, implementeres are also trying to make SPNEGO much more widely
available.

However you are completely correct that upgrading a specific
deployment can be difficult in the absence of negotiation.  I'm not
sure what to do about this problem other than acknowledge it and
encourage use of negotiation.


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