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

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 08 Oct 2009 16:16:35 -0500

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-03
Reviewer: Vijay K. Gurbani
Review Date: Oct 8, 2009
IETF LC End Date: Oct 7, 2009
IESG Telechat date: unknown

Summary: This draft is ready for publication as a Informational;
some minor issues and nits below.

Major issues: 0.
Minor issues: 3.
Nits/editorial comments: 1.

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.

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?
I can use the getaddrinfo() system call and resolve a FQDN
to an IP address in the application code in C/C++ as well.
Conversely, even in Java I can provide a raw IP address
instead of a FQDN.

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.

Nits/editorial comments:

1) S5.1.4, top of page 15, fourth line -- is it "ever exposed"
  or "never exposed"?

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: Wed, 14 Oct 2009 14:51:30 +1300

Vijay,

Thanks for the review.

On 2009-10-09 10:16, Vijay K. Gurbani wrote:
...

> 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).

> 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.

> 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

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.

> they will automatically update this set when a new interface

Yes, we'd probably better s/will likely/might/ to be sure the
statement is accurate.

> 1) S5.1.4, top of page 15, fourth line -- is it "ever 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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 14 Oct 2009 08:53:02 -0500

Brian: Please see inline.

Brian E Carpenter wrote:
>> the upper layer by the socket interface?  [...]
> 
> application has no way to expire an address. 

Ah ... OK, I see where the disconnect is.  When I read your
original text:

I interpreted the "this" in the phrase "this information is
lost once ..." to be the IP address itself, not the TTL.

So, a simple edit is to s/this information/the time to live information/

> handle. Java is only an example and we should make that clearer.

OK.

>> I guess this will depend on the specific implementation of
[...]
> Yes, we'd probably better s/will likely/might/ to be sure the

OK.

>    unfortunate that network layer addresses are usually exposed to

OK.

Thanks,

- vijay