Document: draft-carpenter-renum-needs-work-04
Reviewer: Vijay K. Gurbani
Review Date: Nov. 23, 2009
IETF LC End Date: Nov. 19, 2009
IESG Telechat date: unknown

Summary: This draft is ready for publication as a Informational;
I reviewed the -03 version and all my comments have been
addressed -- but ...

I remain in a state of unease about the discussion Brian and I
had about networking APIs and how they pertain to Java vs. C/C++.
Let me first cut-and-paste the relevant section from -04 that
still makes me uneasy:

  5.1.4. Application layer issues
  ...
  It should be noted that applications are in effect encouraged to be
  aware of and to store IP addresses by the very nature of the socket
  API calls gethostbyname() and getaddrinfo().  It is highly
  unfortunate that many applications use APIs that require the
  application to see and use lower layer objects, such as network-layer
  addresses.  However, the BSD Sockets API was designed and deployed
  before the Domain Name System (DNS) was created, so there were few
  good options at the time.  This issue is made worse by the fact that
  these functions do not return an address lifetime, so that
  applications have no way to know when an address is no longer valid.
  The extension of the same model to cover IPv6 has complicated this
  problem somewhat.  If a model was adopted in which only FQDNs were
  exposed to applications, and addresses were cached with appropriate
  lifetimes within the API, most of these problems would disappear.  It
  should be noted that at least the first part of this is already
  available for some programming languages.  A common example is Java,
  where only FQDNs need to be handled by application code in normal
  circumstances.  This is highly beneficial for programmers who are not
  networking experts, and insulates applications software from many
  aspects of renumbering.  It would be helfpul to have similarly
  abstract, DNS oriented, Networking APIs widely available for C and
  C++.

There are two issues buried in the above paragraph:

(1) Networking APIs do not return a ttl for an address.
(2) Networking APIs should only require the caller to supply a FQDN.

The implication to the reader after going through the above
paragraph appears to be that neither Java nor C/C++ supports
(1), but Java supports (2) and C/C++ do not.

I agree that neither Java nor C/C++ support (1), as best as I know.
However, I am somewhat uncomfortable at the claim that (2) is
supported better in Java than it is in C/C++.

I will note that in C/C++, I can supply either a FQDN or a
dotted-decimal/colon-separated raw IP address as the first
parameter to to getaddrinfo() API:

  int getaddrinfo(const char *nodename, const char  *servname,
    const struct addrinfo *hints, struct addrinfo **res);

In the same vein, the Java InetSocketAddress() constructor is
overloaded to allow for a raw IP address to be passed in as
well as a FQDN string:

  InetSocketAddress(InetAddress addr, int port)
      Creates a socket address from an IP address and a port number.
  InetSocketAddress(String hostname, int port)
      Creates a socket address from a hostname and a port number.

Thus, it appears that both C/C++ and Java support the same amount
of abstraction.  The only difference is that in C/C++, the
socket is treated as a file descriptor following the Unix
convention of abstracting I/O behind a descriptor of some sort.
In Java, you get back an object -- but this is an artifact of the
specific programming language and the environment.

If Brian agrees that C/C++ and Java are analogous in both (1) and
(2), then we can agree to word-smithing the paragraph above to
reflect this quickly.  If not, then I am probably missing something
germane and I hope Brian fills me in so we can proceed on this
draft expeditiously.

Sorry, I am not being difficult -- just trying to ensure that
my understanding lines up with Brian's.