[Gen-art] Gen-ART review of draft-carpenter-renum-needs-work-04

["Vijay K. Gurbani" <[e-mail]>]

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

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.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/