Subject: [SPKM] Interoperability

From: Sam Hartman <[email-masked]>
Date: Tue, 31 Oct 2006 14:23:50 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/spkm

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 31 Oct 2006 15:10:20 -0600

> not sure we're maintaining interoperability we're changing the OID.

I am not sure that the draft as it stands maintains interop with the
imaginary implementations of the original SPKM-3.

Unless others can explain that it does, in fact, do this, then that
means we're changing the OID.

> want to implement both mechanisms can do so.

Indeed.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 31 Oct 2006 15:12:46 -0600

>   market deploying something that does not meet your spec.  That is

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.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 31 Oct 2006 16:19:04 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Tue, Oct 31, 2006 at 02:23:50PM -0500, Sam Hartman
    Nicolas> wrote:
    >> 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.

    Nicolas> If we cannot get a spec that will meet our needs in time
    Nicolas> for the market then the proposed protocol could go to
    Nicolas> Informational and a spec that does meet our needs can
    Nicolas> later go to Proposed-Standard, using a different OID.

Yes.
I don't consider it a failure if the market has to do something while we work on a spec.

I will not sponsor this as informational, but nothing stops the
authors from going to the rfc editor.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 31 Oct 2006 15:31:06 -0600

> authors from going to the rfc editor.

Right.  I think this is a possible outcome of the BoF.

Nico
--