-----Original Message-----
From: ietf <ietf-bounces@xxxxxxxx> on behalf of Toerless Eckert <tte@xxxxxxxxx>
Date: Wednesday, November 1, 2017 at 7:55 AM
To: "lear@xxxxxxxxx" <lear@xxxxxxxxx>
Cc: "ietf@xxxxxxxx" <ietf@xxxxxxxx>
Subject: Re: letting IETF build on top of Open Source technology
So, whats the right terminology here for at least the two classes
that i think are easy to destinguish:
a) In one case i have FOSS that implements a new protocol like rsync does,
and interop means that you want two independent implementations support
the protocol.
b) In another case, which i think are all your examples, you have some
form of "service" which is providing some form of "API" and interop
really means that only one implementation is required to show how
it works with multiple clients of the service.
I also think that b) is easier to adopt because
- interop does not require you to find other implementations of the
same protocol/service
- An API that MUST be used by a third party client is more naturally
documented than a protocol that was meant to be used between multiple
instances of a single FOSS software (typical a) case).
[cue] I agree.When I think about opens source software that would stand up well in the face of the 5 requirements in section 2 of the draft, your class b would certainly stand a better chance. When I read the draft, I saw it as targeting that class of open source projects.
Cheers,
Charles
Cheers
Toerless
On Mon, Oct 30, 2017 at 11:19:19PM +0100, Eliot Lear wrote:
> The obvious example would be the vast quantities of YANG that are
> cropping up everywhere. Another one that many reference outside of the
> IETF context is ArcSight CEF, which is an overlay on SYSLOG that is
> frequently used. When there's active development on a project, this
> isn't a good fit, due to feature velocity. Even there, though, some may
> wish to declare certain interfaces both public and stable. I could
> imagine the git team doing that, for instance, given the number of front
> ends there are with it.
>
> Eliot