Subject: Re: [nbs] NBS and TCP connection identification

From: RJ Atkinson <[email-masked]>
Date: Wed, 13 Oct 2010 08:30:42 -0400

On 5th October, David Harrington wrote:
> If consensus is that this is the goal, then the BOF
> should have participation from OS vendors indicating
> an interest in taking on this burden. 

I agree that would be highly desirable.

It is at least conceivable to me that the proposed new 
C/C++ API could be implemented as a library, containing 
calls to existing POSIX APIs [e.g. getservbyname(), 
gethostbyname(), and existing Sockets APIs] internally 
within the library.

Such a library implementation likely would have visibly
worse performance than just calling the POSIX functions 
directly, for example due to the function call overhead, 
but the library might be helpful in making the API more 
widely available on diverse OS platforms.

My main concern is application portability, not only across
operating systems, but also across a range of Internet 
networking protocols underneath.

> The BOF will also need to explain why this work belongs in IETF,
> rather than in other SDOs.

1) C/C++ API work

C/C++ networking interfaces have been standardised by 
IEEE POSIX.  So it seems clear that IEEE POSIX is the 
appropriate SDO for networking interface standardisation.  

That said, the IETF does have a history of creating
non-standard Informational RFCs proposing networking 
interfaces.  

Examples of this practice include:
	RFC-5014
	RFC-4584
	RFC-3542

In my mind, any API document produced in this area should 
follow that model, and also should be offered as a contribution 
to IEEE POSIX.

(I'm unclear how active the IEEE POSIX effort is these days,
but certainly IEEE has a very active Standards activity.)	

I think 3 aspects of the proposed API work are important 
enough that they should be explicitly required by any WG Charter:

A) The API should support use of names for all objects in the API,
   as various folks (e.g. Dave Thaler) have already suggested.
   [This means that raw "magic numbers", IP addresses, and odd
   "Sockaddr" structures are all best avoided.]

B) The API should be so generic that it can be used without any 
   special hooks or extensions over the wide gamut of networking
   protocols.  For example, an application written to this API 
   ought to run without modification equally well over IPv4, IPv6, 
   SHIM6, HIP, and ILNP.  The choice of networking protocol(s)
   to use also ought to be left to the underlying OS, not signalled
   by the application.

C) A corollary to (B) is that the name-based API should be totally 
   decoupled from any proposed set of protocol extensions.  If the
   API requires those extensions or assumes the availability of
   those extensions, then the protocol-independence is lost --
   and protocol-independence is the biggest potential value-add here.

2) Java API work

  There is no IETF value-add with respect to Java.  Java already
  has standardised name-oriented and nicely abstracted APIs for 
  networking.  So no work on Java appears to be needed.

  In any event, other clearly active activities cover Java APIs,
  so proposals for Java extensions should be taken there.

> Christian's paper proposed changes to protocols,
> such as transport protocol handshakes.
> The BOF should explain in detail how the changes proposed
> would happen only on hosts, not on routers, switches, etc.

For protocols that have existing active IETF WGs, then it 
seems to me that proposal to change those protocols ought 
to be undertaken within those WGs.

For example, any proposal to change/enhance TCP ought 
to be handled within the existing IETF TCPM WG.  

Yours,

Ran