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

[Brian E Carpenter <[e-mail]>]

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

On 2009-11-24 12:21, Vijay K. Gurbani wrote:
> 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