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: v...@{alcatel-lucent.com,bell-labs.com,acm.org}
Web: http://ect.bell-labs.com/who/vkg/
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
