Subject: [Tsvwg] API related DISCUSS for draft-ietf-tcpm-tcp-uto

From: Alfred Hönes <[email-masked]>
Date: Wed, 21 Jan 2009 20:57:51 +0100 (MEZ)

I stumbled over the mid-December IESG deliberations regarding the
I-D after LC, draft-ietf-tcpm-tcp-uto, and got stuck at the DISCUSS
position in favor of an API specification in the draft.

I have serious concerns with that position.

For the most part, the IETF has refrained from doing that entirely,
and when it indeed dealt with specifying APIs, it was based on
implementation experience.

The still not finalized SCTP socket API spec story seems to
support my observation that strong feedback from implementations
and use cases can have an important impact on the details of an
API specification, its resulting versatility, and its acceptance.

Externally visible behavior has traditionally been specified first,
giving the API time to evolve.  Therefore, I strongly suggest to *not*
add the specification of a concrete extension of the sockets API (in
support of TCP-UTO) to the draft under consideration, at this stage.

This topic should be re-visited when, at some time in the future,
a revised document targeting at Draft Standard for TCP-UTO might
be considered.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Chris Newman <[email-masked]>
Date: Thu, 22 Jan 2009 08:54:05 -0800

refraining from APIs (we have done APIs such as getaddrinfo, advanced 
sockets, LDAP C API, GSSAPI, etc).  If you read my discuss position, I am 
not asking for inclusion of the API in this spec, but I am asking for the 
specification to be revised to either:

* Make it clear the intention is to have communication of this information 
between
  application protocol implementations and the TCP stack.
* Have an informative reference to the forum where API development is 
occurring so such
  communication can become possible in real world implementations rather 
than prototypes.

  or

* Make it clear this is implemented only in the TCP stack and applications 
are not involved.

		- Chris

--On January 21, 2009 20:57:51 +0100 "Alfred H?nes" <[email-masked]> wrote:

> Hello,
>   Alfred H?nes.

---

From: Chris Newman <[email-masked]>
Date: Thu, 22 Jan 2009 09:16:20 -0800

concern.  I do hope those interested in getting this deployed in 
applications will engage the implementers to help avoid deployment of 
disjoint API variants among Posix/socket API systems.

		- Chris

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 23 Jan 2009 10:08:26 +0200

> and when it indeed dealt with specifying APIs,

I humbly think that is a big mistake.

There are quite a bunch of otherwise good IETF technologies that would 
probably have gained much wider acceptance, had they had an Informational API, 
rather than none.

I could start with various DNS record types, like SRV, NAPTR, etc - 
implementors stick to A and AAAA because these two do have "easy to use" 
standard APIs.

IPsec is another example. It was "unprogrammable", at least until the very 
late BTNS working group. Compare to SSL/TLS, which though it has no "standard" 
API, can be layered easily atop sockets.

Specifying APIs is perhaps not absolutely needed, but I feel concepting a sane 
API, and outlining its architecture in an informational appendix should be a 
MUST (as applicable).

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D