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

"Vijay K. Gurbani" <vkg@alcatel-lucent.com> Thu, 08 October 2009 21:15 UTC

Return-Path: <vkg@alcatel-lucent.com>
X-Original-To: gen-art@core3.amsl.com
Delivered-To: gen-art@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F62D3A6968 for <gen-art@core3.amsl.com>; Thu, 8 Oct 2009 14:15:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.442
X-Spam-Level:
X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gm1KbpMZk9s8 for <gen-art@core3.amsl.com>; Thu, 8 Oct 2009 14:15:15 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 472043A681A for <gen-art@ietf.org>; Thu, 8 Oct 2009 14:15:15 -0700 (PDT)
Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id n98LGZO3000041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Oct 2009 16:16:36 -0500 (CDT)
Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n98LGZFH017893; Thu, 8 Oct 2009 16:16:35 -0500 (CDT)
Message-ID: <4ACE56B3.1070705@lucent.com>
Date: Thu, 08 Oct 2009 16:16:35 -0500
From: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Cc: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, gen-art@ietf.org
Subject: [Gen-art] Gen-ART review of draft-carpenter-renum-needs-work-03
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Oct 2009 21:15:16 -0000

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/