Vijay, Thanks for the review.
On 2009-10-09 10:16, Vijay K. Gurbani wrote: ... > Minor Issues: > 1) S1, last paragraph: I am not sure I understand the following: > > Even when an address is leased for a finite time by DHCP > or SLAAC, or when it is derived from a DNS record with a > finite time to live, this information is lost once the > address has been passed to an upper layer by the socket > interface. > > I am sure I am missing something here, but why is this > information considered lost once it has been passed to > the upper layer by the socket interface? In fact, it is > the other way around -- it is the upper layers that query the > network layer using DNS APIs for this IP address. The network > layer in a host always knows its IP address, right? If our > email exchange results in any clarification, it can be put into > the text, but for right now I don't have any suggested text. As far as I know, neither gethostbyname() nor getaddressinfo() returns the remaining TTL of the address(es) supplied. So the application has no way to expire an address. And also as far as I know, an application has no way to discover the remaining lifetime of its own host's IP address(es), so if it passes them to a third party application, the third party has no way to expire an address. It's my impression that application programmers have solved this problem rather inconsistently (e.g. by ignoring it, or by setting an arbitrary timeout on cached addresses, or by never timing them out at all until there's a restart). > > 2) S5.1.4, page 15; it says that: > > It should be noted that at least the first part of this > is already available for some programming languages, > notably Java, where only FQDNs need to be handled by > application code. > > Again, I am not sure I understand. Why is Java special here? Because the ordinary Java application programmer has a much simpler interface than BSD sockets, which accepts names as the primary handle. Java is only an example and we should make that clearer. > I can use the getaddrinfo() system call and resolve a FQDN > to an IP address in the application code in C/C++ as well. Of course, but then you also have to handle all the logic of IPv6/IPv6 coexistence etc. Java hides it all. > Conversely, even in Java I can provide a raw IP address > instead of a FQDN. Sure, if you are a systems hacker. But average programmers really do find FQDNs easier. The critical point is that with an abstracted API, applications never need to perform FQDN to something else (IP address or Sockaddr) conversion. By contrast, with the traditional BSD Sockets C-language API, applications *always* need to make that FQDN to something else (to Sockaddr in the case of BSD) conversion [e.g. using gethostbyname()]. Applications using the abstracted API are wildly less likely to use low-level objects (e.g. IPv4 address) either internally or in the application-layer protocol. Instead, such apps are very likely to use the FQDN instead. > > 3) S5.1.4, page 15, it says that: > > Server applications will likely need to be restarted > when the host they contain is renumbered, to ensure that > they are listening on a port and socket bound to the > new address. > > Is this still true if a server process is bound to INADDR_ANY? > I guess this will depend on the specific implementation of > the IP stack -- I do not know whether modern kernels expand > INADDR_ANY to the set of interfaces available only when a > process first binds itself to the interfaces, or whether > they will automatically update this set when a new interface > is added. Yes, we'd probably better s/will likely/might/ to be sure the statement is accurate. > > Nits/editorial comments: > > 1) S5.1.4, top of page 15, fourth line -- is it "ever exposed" > or "never exposed"? I think our intention would be clearer if we wrote It is highly unfortunate that network layer addresses are usually exposed to application sessions. This is really the same point as above (Java API). We're saying that the fact that applications ever deal with addresses is a design error (which of course goes back to 1983 or so). Opinions may vary! Brian > > Thanks, > > - vijay _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
