Re: [Gen-art] Gen-ART review of draft-carpenter-renum-needs-work-04
Brian E Carpenter wrote:
Vijay,
Brian: Thanks for attending to my comments. More inline.
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.
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.
We have quite a few other changes to make following IESG comments,
so there will definitely be a new version.
OK, thank you.
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: v...@{alcatel-lucent.com,bell-labs.com,acm.org}
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-carpenter-renum-needs-work-04
On 30 Nov 2009, at 12:51 , Vijay K. Gurbani wrote: ...it is not the case that Java is exposing some additional functionality that 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 ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-carpenter-renum-needs-work-04
Ran Atkinson wrote:
On 30 Nov 2009, at 12:51 , Vijay K. Gurbani wrote:
...it is not the
case that Java is exposing some additional functionality that
C/C++ do not.
Indeed. That is precisely our point, although phrased in an
inverse manner.
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
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: v...@{alcatel-lucent.com,bell-labs.com,acm.org}
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-carpenter-renum-needs-work-04
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 ___ Gen-art
[Gen-art] Gen-ART review of draft-carpenter-renum-needs-work-04
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: v...@{alcatel-lucent.com,bell-labs.com,acm.org}
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
