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

From: liu dapeng <[email-masked]>
Date: Mon, 11 Apr 2011 11:06:27 +0800

Hi Dave,

Thanks for the comments.

2011/3/28, Dave Thaler <[email-masked]>:
> 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.

==>
We aggree to define only abstract API. probably we should just use
setsockopt as one implementation example? will update in the next
version.

> 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.

==>
Thanks for the information. As mentioned above, we may use setsockopt
as one possible implementation example. Regarding RFC3678, is that a
concrete API?

> 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).

==>
Does abstract API need to list the detailed data structure or we can
just give the functional description of the API?

Best Regards,
Dapeng Liu

> 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.
==>
This API will be redesigned in the updated version.

> 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.

==>
Could you help to give a pointer of the non-standard Windows interface
selection API? Thanks.

> -Dave
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>