Subject: Re: [lemonade] some questions in draft-ietf-lemonade-notifications-03

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 16 Aug 2006 11:34:38 +0200

Randall Gellens writes:
> At 11:10 AM +0100 8/9/06, Ben Last wrote:
>>  Sure, it's more complex from the OS's point of view, but that's 
>>  hidden from the programmer.
>
> I think it would be a mistake to make a protocol more complex and 
> expensive simply because programmers can implement it by taking 
> advantage of existing libraries and APIs.  Good programmers 
> understand, at least in general terms, what happens under the hood.

So do bad programmers when there's a bug. Consider fixing something 
which can be reproduced by doing x using server y and client z . A 
fairly common task for the maintainers of y and z, ie. for everyone. 
The very first step is necessarily protocol-level analysis, so all that 
"hidden" complexity is uncovered right away.

Arnt

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Ned Freed <[email-masked]>
Date: Sun, 20 Aug 2006 11:00:17 -0700 (PDT)

> > understand, at least in general terms, what happens under the hood.

Another problem IMO is that it is quite rare for those "existing libraries and
APIs" to actually exist on all platforms of interest. And this is especially
true here, where we're supposed to be dealing with an even wider range of
devices than is perhaps the norm.

Let's please not forget the "diverse service endpoints" phrase that appears in
the title of this group.

Mind you, this doesn't mean we should attempt to cater to the vagarities of
devices that fail to either implement or provide access to basic lower layer
services like TCP, at least not in our standards-track work. There has to be a
nontrivial lowest common denominator in there somewhere.

> "hidden" complexity is uncovered right away.

Quite true. And when the problem actually turns out to be in one of those
libraries (as it does all too often) gettting it fixed can be a major
undertaking. Indeed, the situation in regards to library dependencies has
gotten so bad in some quarters I often hope for the issue to be in my own code,
because at least that way I can find and fix it.

				Ned

---

From: Mark Crispin <[email-masked]>
Date: Sun, 20 Aug 2006 11:52:50 -0700 (PDT)

On Sun, 20 Aug 2006, Ned Freed wrote:
> Another problem IMO is that it is quite rare for those "existing 
> libraries and APIs" to actually exist on all platforms of interest. And 
> this is especially true here, where we're supposed to be dealing with an 
> even wider range of devices than is perhaps the norm.

Indeed.  It is singularly unhelpful to tell someone to use an API that is 
unobtainable on that person's platform.

In fact, I would go so far as to propose an IETF BCP that protocol 
specifications MUST NOT be defined to use any API unless the proponent 
commits to provide, and support, an implementation of that API free of 
charge for all platforms; and to post a security bond sufficient to fund 
such provision and support should the proponent become unable to fufill 
this responsibility.

If someone were to say "no problem", then I have a couple of TOPS-20 
systems that need provisioning... ;-)  Hey, it's got a C compiler. ;-)

> Quite true. And when the problem actually turns out to be in one of 
> those libraries (as it does all too often) gettting it fixed can be a 
> major undertaking. Indeed, the situation in regards to library 
> dependencies has gotten so bad in some quarters I often hope for the 
> issue to be in my own code, because at least that way I can find and fix 
> it.

True story:

The UW IMAP and POP3 servers were broken by the GSSAPI in krb5-1.5.  It 
keels over deep in the internals of GSSAPI with an assertion failure. 
It's their bug, they've fixed it in 1.5.1, and in all fairness they were 
fairly quick in saying "mea culpa" and getting a fix out.

Nonetheless...  It happened while I was on a one-month vacation.  I got 
egg on my face for something that was not my fault, and had nothing to do 
with.  Why didn't my "buggy" code properly initialize GSSAPI, etc. 
[Because there is no "initialize GSSAPI", that's why!  And by the way, 
that thing that wasn't initialized was creeping featurism in GSSAPI that 
is completely orthogonal to the purpose of GSSAPI and Kerberos!!]

I did what I could.  I put out a posting on the UW IMAP user list warning 
people about upgrading to krb5-1.5, suggesting that they wait until 
krb5-1.5.1, and providing the patch to krb-1.5 that fixes the problem. 
Above all else, (thankfully!) krb5-1.5 is new enough that most people do 
not run it and hopefully never will since 1.5.1 is coming.

Still, I expect some more incoming eggs before it blows over.

APIs can be a very good and useful thing.  I wrote (and use) the c-client 
API.  UW imapd uses c-client along with the GSSAPI and OpenSSL APIs. 
Pine adds two APIs (pico and pith) of its own, and uses some others (such 
as LDAP).

So I'm not anti-API.  However, I am VERY cautious when adding new APIs to 
the mix.  Even with your own APIs, you stand the risk of a cascading 
regression.  External APIs are a much greater risk.

I'm even more cautious when adding APIs to a protocol specification.  The 
SASL profile for Kerberos 5 is defined by GSSAPI.  This may be a good 
thing in some ways, but in other ways it's quite a problem.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.