Subject: grow: WGLC for draft-ietf-grow-embed-addr-00.txt

From: David Meyer <[email-masked]>
Date: Wed, 3 Mar 2004 23:12:14 -0800

This note starts the working group last call for 
	draft-ietf-grow-embed-addr-00.txt. The last call will end
	on 17 Mar 2004 at 1700 PST. Please send comments to the
	list.

	Thanks,

	Dave
_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive:        http://darkwing.uoregon.edu/~llynch/grow/

---

From: Pekka Savola <[email-masked]>
Date: Sun, 7 Mar 2004 17:52:18 +0200 (EET)

> 	on 17 Mar 2004 at 1700 PST. Please send comments to the

Nowhere is the category stated?  Is this for Informational or BCP?  It 
could be both, but as this seems so obvious, perhaps Info seems 
better.

substantial
----------

==> just as a general note: for many intents and purposes, embedding a 
DNS name is almost equally problematic as embedding the IP address.  
For example, if you glue "www.microsoft.com" (or whatever), which is 
not easily changeable in the event of problems like the netgear 
incident, the effects will be the same.

As the document effectively recommends this, it might be worth noting
that this has some limitations as well, but properly used, could be
helpful (e.g., if netgear would configure its servers to look up NTP
servers from e.g., "ntp-servers.config.netgear.com" -- this would
allow "remote control" of a sort).

....

   Whenever possible, default configurations, documentation, and example
   configurations for Internet hosts should use Private Internet
   Addresses, as defined by RFC 1918 [6], rather than unique, globally
   routable IP addresses.

==> I have to disagree with this.  Documentation and examples should 
use the specific example resources such as example.com and 
192.0.2.0/24.  Using private addresses is harmful (IMHO) because it 
leads to users thinking that using private addresses solves their 
problems.

So,
 - no default configs with IP addresses, please
 - do not use private addresses in examples, etc.

editorial (more or less)
---------

==> please rewrite the abstract.  It's too long -- maybe something
like 5-10 lines would be preferable; some of that it certainly
material for the Introduction section, which is rather short as it is.

==> I assume you're using XML.  Because sections are quite short, I 
recomment using the tag: <?rfc compact='yes' subcompact='no'?> -- this 
will compress the document a bit.

==> revision history should probably have a mention like:
[[ RFC-Editor note: remove before publication ]]

                                                     For instance,
   one common load-balancing technique employs multiple DNS records with
   the same name that are then rotated in a round-robin fashion in the
   set of answers returned by the Berkeley Internet Name Daemon (BIND)
   and other DNS server implementations.

==> remove "the Berkeley Internet Name Daemon (BIND) and other" -- 
irrelevant.

  In this way, IP address blocks containing addresses that have been
   embedded into the configuration of many Internet hosts become
   encumbered by their historical use. This may interfere with the
   ability of the Internet Assigned Numbers Authority (IANA) and the
   Internet Registry (IR) hierarchy to usefully reallocate IP address
   blocks. This is of particular concern as the IPv4 address space nears
   exhaustion. Note that, to facilitate IP address reuse, RFC 2050 [2],
   encourages Internet Service Providers (ISPs) to treat address
   assignments as "loans".

==> remove the "This is of particular concern ..." -sentence; it is 
not accurate, there are so many IPv4 addresses left that there's no 
worry about that.. and there's no need to worry about that here.

   Because consumers are not necessarily capable, experienced operators
   of Internet hosts, they are not able to be relied upon to implement a
   fix if and when problems arise.

==> this sounds awkward, "operators of Internet hosts" ?!? Maybe 
rewrite to:

   Because consumers are not necessarily capable or experienced to 
   operate the hosts, they cannot be relied upon to implement a
   fix if and when problems arise.

...

  Vendors should provide an operator interface for every feature that
   generates unsolicited IP traffic.  A prime example of this that the
   Domain Name System resolver should have an interface enabling the

==> s/this/this is/ ?

  operator to either explicitl set the servers of his choosing or to
 
==> s/explicitl/explicitly/

...

   Service providers and enterprise network operators should advertise
   the identities of suitable local services.  For instance, the DHCP
   protocol, as defined by RFC 2132 [5], enables one to configure a
   server to answer queries regarding available servers to clients that
   [...]

==> isn't it obvious enough that DHCP can be used to configure DNS 
servers?  If so, remove "the" and "protocol, as defined by RFC 2122,"

  such, their widespread citations in public service indexes interferes
   with the ability to reconfigure the service as necessary to address
   unexpected, increased workloads.

==> "workloads" sounds pretty funny.  "traffic" any better?

References

==> these must be split to "Informative" and "Normative" references.

==> reference [7] is missing, it seems.

   [5]  Alexander, S., "DHCP Options and BOOTP Vendor Extensions", RFC
        2132, March 1997.

==> maybe refer to the core DHCP spec itself?

Appendix A. Background

   In June 2003, the University of Wisconsin discovered that the network
   product vendor named NetGear had manufactured and shipped over

==> it's probably not appropriate to name the vendor in this draft.  
Just say "a network product provider" or whatever.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: David Meyer <[email-masked]>
Date: Sun, 7 Mar 2004 16:51:11 -0800

Thanks Pekka. I'll work with Dave (and on the other doc) to
incorporate your comments. BTW, both of these documents have I-D
nits, which will have too be corrected (I'll do the communities
one (obviously), and will work with Dave on this one).

Thanks again for the detailed and thoughtful comments.

Dave