Subject: [mif] Comments on draft-liu-mif-api-extension-04

From: Dave Thaler <[email-masked]>
Date: Mon, 28 Mar 2011 12:52:04 +0000

First two comments from last IETF that have not been 
addressed yet:

1) Although the draft does now include some text saying it
intends to define an abstract API, it actually defines a 
concrete one.  For example, saying that an API is a socket
option used with setsockopt makes it a concrete API.
And saying that a parameter is a "char *" rather than a 
"string" makes it a concrete API.

2) My understanding is that the POSIX socket APIs are defined
by the Austin Group, and standardized by the IEEE and the
Open Group.  When we did RFC 3678, we learned that the
Austin Group now considers new socket options and ioctls
harmful, since they're not typesafe.  As a result, the API was
fixed to use new methods instead.  Unfortunately by then,
some implementations already started using socket options/
ioctls, and so those were moved into an Appendix.

New comments:

3) "struct parameter" is underspecified.  In an abstract API
document, one would need to list the parameters and their
meanings and abstract types (string, integer, whatever).

4) gethostbyname was obsoleted by getaddrinfo.  And it's
not defined as a DNS API.   For more info, see
http://pubs.opengroup.org/onlinepubs/009695399/functions/gethostbyname.html
and RFC 6055.

5) For interface selection, there are existing (non-standard)
APIs on Windows and perhaps other OS's too.   I'd recommend
looking at what is already in use today and making sure the
abstract API is defined with that information in mind.

-Dave