Re: [TLS] To API or not (Re: TLS renegotiation issue)

["Blumenthal, Uri - 0662 - MITLL" <uri at ll.mit.edu>]

IETF can't write precise API because those are application-specific. IETF can and often should write Abstract Service Interface (ASI) specs that define the minimal amount of data that one component needs from another one to be of use to it.

True, ASI is no panacea. But (as IMHO SNMPv3 experience proved) it benefits much mpre than it inconveniences.


----- Original Message -----
From: Nicolas Williams <Nicolas.Williams at sun.com>
To: David Harrington <ietfdbh at comcast.net>
Cc: Blumenthal, Uri - 0662 - MITLL; 'Marsh Ray' <marsh at extendedsubset.com>; tls at ietf.org <tls at ietf.org>
Sent: Fri Nov 06 18:09:41 2009
Subject: To API or not (Re: [TLS] TLS renegotiation issue)

On Sat, Nov 07, 2009 at 06:39:48AM +0800, David Harrington wrote:

Of course, the issue here is not "must the IETF provide APIs?" but "can
the IETF provide APIs?".  The answer to that is a resounding "yes".

> I was probably the strongest proponent of using abstract APIs
> (actually ASIs - abstract service interfaces) to depict data flows
> between parts of the system. 
> 
> Let me observe that those ASIs have made it almost impossible to
> update the pieces of SNMPv3, because the ASIs act as design
> constraints. The strong architectural model made it very difficult to
> update the SMI without forcing changes to the ASIs. The strong
> architectural model made it very difficult to update the operations

I consider this a feature.  Not that I want to slow down development,
mind you.  Nor that I want to stay wedded to an ASI architecture that
turns out to be resistant to usefule changes.  Rather, changes to the
protocol should either be mindful of the abstract interfaces that have
been specified (i.e., the existing interfaces, possibly with extensions,
should continue to work), or they should introduce a replacement set of
interfaces.

> set of the SNMP protocol. Both of these efforts resulted in failed
> WGs. Adding support for existing SSH security infrastructure took
> three documents because we had  to modify the architecture, including
> all the affected ASIs. What might have taken months to complete took
> years - largely because of the use of ASIs in the architecture.

If the ASIs made it too hard to change the protocol in useful ways, then
the ASIs should be replaced.

> Many of the people who worked developed Netconf were involved in the
> SNMPv3 architecture effort, and subsequent updates. Look at the
> Netconf architecural model - it uses very simple, very nebulous
> layering as the borders between portions, not ASIs. This is a
> dramatically simpler and easier approach to work with.

I agree that it is dramatically simpler to write such documents.  I
don't agree that the result is necessarily better.  There's a whole
continuum of degree of formalism that we can use in our documents.  What
degree of formalism is best will depend on context (including who the
document authors and implementors are).  There will be contexts where
using XML schemas is useful, and ones where that would be overkill, for
example; replace XML with ASN.1/SDL/whatever.  There are contexts where
you want to use pseudo-code, or even actual source code to describe as
formally as possible, what must be done, while in other contexts "test
vectors", or just plain English language prose will do.

I think that abstract interfaces would be useful for TLS.  Most would
probably disagree.  If someday I get to be a TLS implementor, I may well
submit an individual submission I-D describing an abstract TLS API, and
maybe then I can convince the rest.  Until then I'm happy to be in the
minority, with some minor exceptions: I think it's important forthe base
TLS spec to speak of TLS connections, channel bindings for TLS
connections, and channel binding to TLS connections.

> I strongly advise you to be careful what you wish for. 

Thanks.

Nico
--