[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/
- [Gen-art] Gen-ART review of draft-carpenter-renum… Vijay K. Gurbani
- Re: [Gen-art] Gen-ART review of draft-carpenter-r… Brian E Carpenter
- Re: [Gen-art] Gen-ART review of draft-carpenter-r… Vijay K. Gurbani