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

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 23 Nov 2009 17:21:39 -0600

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/

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 29 Nov 2009 09:42:50 +1300

Vijay,

I think the difference is that the Java run-time system includes
the ability to "automagically" prefer v6 or v4. Specifically, the
JDK provides java.net.preferIPv4Stack and java.net.preferIPv6Addresses.
So if the programmer chooses to use FQDNs then the run-time will
act according to those preferences. In C/C++ the programmer has
to implement such preferences with extra logic. I agree that this is
probably badly expressed in the current text.

We have quite a few other changes to make following IESG comments,
so there will definitely be a new version.

Regards
   Brian

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 30 Nov 2009 11:51:55 -0600

> Vijay,

Brian: Thanks for attending to my comments.  More inline.

> to implement such preferences with extra logic. 

But these -- java.net.preferIPv4Stack and
java.net.preferIPv6Addresses -- are simply networking properties
that the programmer has to remember to set (I am sure they
have sane default values, but regardless, they are attributes
that can be modified by the programmer.)

In much the same vein, someone could write a wrapper around
the C/C++ getaddrinfo() API to prefer IPv4 or IPv6.

I agree that setting properties in Java is much easier than
writing a wrapper around an API, but regardless, it is not the
case that Java is exposing some additional functionality that
C/C++ do not.  Java is just packaging the functionality in
an attractive, easy to use manner.

> so there will definitely be a new version.

OK, thank you.

- vijay

---

From: Ran Atkinson <[email-masked]>
Date: Mon, 30 Nov 2009 13:07:36 -0500

On 30  Nov 2009, at 12:51 , Vijay K. Gurbani wrote:
> ...it is not the
> C/C++ do not. 

Indeed.  That is precisely our point, although phrased in an
inverse manner.

The more abstracted Java Networking APIs *HIDE* some low-level/
more-specific networking information from application programmers.  

As with the standard situation in Computer Science, such use of
information hiding encourages application programmers to use 
properly high-level and abstract designs both for their applications 
and their application protocols.  

In turn, this tends to make the resulting applications more 
tolerant of changes to low-level networking details (e.g. changes 
to an IP address).  As our draft is entirely about the issues and
limitations of IP renumbering, this is precisely on point and
within scope for our draft.

As an aside, I'm told that Apple's COCOA APIs (and possibly also 
some proprietary Microsoft Windows APIs) also engage in significant 
information hiding, for the same reasons as the more abstract Java
networking APIs, and likely with the same benefits.  However, 
those are not open-standard C/C++ networking APIs, but rather 
platform-specific networking APIs.  So they don't make very good
examples.  The abstracted Java networking APIs are, however, both
platform-independent and open-standard, which is why those are 
particularly good examples for our document.

[And yes, I know that some Java instances might contain ugly
low-level networking APIs.   THese are not commonly used,
however, and programmers don't have the equivalent choice of
API abstraction in open-standard C/C++ today (at least for 
platform-independent software) that they do today in open-standard
Java.  The point is not that one could write bad software.  The 
point is that Java encourages one to write good software by having 
suitably abstracted APIs as the "normal" and most commonly used/taught 
networking APIs.  It is a pity that such abstracted APIs were not
openly specified by the IETF during the protracted IPv6 process.]

Cheers,

Ran

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 30 Nov 2009 12:16:06 -0600

> Indeed.  That is precisely our point, although phrased in an

I think we are in agreement.  The main issue I wanted to
make sure got across is exactly what I wrote previously:

   ...it is not the case that Java is exposing some additional
   functionality that C/C++ do not.  Java is just packaging
   the functionality in an attractive, easy to use manner.

Any attempts to word-smith this in a manner that does not
give undue advantage to a particular language should be good.

In a certain sense, Java is a language as well as a platform.
Thus, many ideas can be abstracted a bit better that one could
do so in C++.  To take an equivalent example, one could just
as well include these IPv4/IPv6 APIs in the C++ boost library
and attain the same level of abstraction as Java does.

Thanks,

- vijay