Spencer Dawkins wrote:
Hi, Spencer (et al.),
These are useful comments, but in the interest of moving forward on this
version, continued wordsmithing is less useful than catching typos and
complete errors at this point.
It would be useful if you could identify which of these issues you feel
are show-stoppers at this point.
--With regard to bcast/discovery, these issues have been addressed before; no version of text will be 100% clear to any set of readers. (detailed reply below)
With regard to references, IMO, URLs are inappropriate for RFCs unless there are no alternate sources, and only for non-normative (to give credit, NOT for 'additional info'). This is because, as you point out, most of the URLs have moved already. Google/etc will suffice, and we shouldn't waste space or energy on such empemeral data.
Joe
... > 5 Broadcasting and Discovery > > Subnetworks fall into two categories: > point-to-point and shared. A > point-to-point subnet has exactly two endpoint > components (hosts or > routers); a shared link has more than two, using > either an inherent > broadcast media (e.g., Ethernet, radio) or on a > switching layer > hidden from the network layer (switched Ethernet, > Myrinet [MYR], > ATM). Switched subnetworks handle broadcast by > copying broadcast > > Could this sentence say "by forwarding broadcast > packets on all other > interfaces to ensure..."?
The current text implies "send TO each destination"; sending ON each interface makes implications about the technology which don't apply to some multistage switched nets.
> packets to ensure each end system receives a copy > of each packet. > > Could we insert "Centralized databases also insert new > failure points and > scaling hot-spots into the network." before the last > sentence in the > following paragraph?
Sure. But it's somewhat obvious (i.e., do we really need to say WHY centralization is bad?).
> The lack of broadcast can impede the performance of > these protocols, > or render them inoperable (e.g. DHCP). ARP-like > link address lookup > can be provided by a centralized database, but at > the expense of > potentially higher response latency and the need > for nodes to have > explicit knowledge of the ARP server address. > Shared links should > support native, link-layer subnet broadcast. > > 6 Multicasting > > Receivers also need to be designed to accept > packets addressed to > some number of multicast addresses in addition to > the unicast packets > specifically addressed to them. How many multicast > addresses need to > be supported by a host depends on the requirements > of the associated > host; at least several dozen will meet most current > needs. > > The last phrase doesn't parse well for me. Is it > saying "few hosts > must accept multicast packets from more than a few > dozen multicast > addresses"?
Yes. Since it appears to have worked, perhaps it's sufficient. :-)
> On low-speed networks the multicast address > recognition function may > be readily implemented in host software, but on > high speed networks > it should be implemented in subnetwork hardware. > This hardware need > not be complete; for example, many Ethernet > interfaces implement a > "hashing" function that passes all of the multicast > (and unicast) > traffic to which the associated host subscribes, > plus some small > fraction of multicast traffic to which the host > does not subscribe. > Host/router software then has to discard the > unwanted packets that > pass the hardware filter. > > There does not need to be a one-to-one mapping > between subnetwork > multicast address and IP multicast address. An > address overlap may > significantly degrade the filtering capability of a > receiver's > hardware multicast address filter. A subnetwork > supporting only > > Is this sentence saying "If more than one IP multicast > address makes into > a subnetwork multicast address, this many-to-one > mapping may significantly > degrade the filtering capacity of a receiver's > hardware multicast address > filter", or something else? "Address overlap" is too > ambiguous for me... > > broadcast should use this service for multicast and > must rely on > software filtering. >
The rest of the sentence explains it - hardware stops being useful and thus requires software.
> References
FYI, as you're obsevering, URLs are somewhat ephemeral. They should only be used where they ADD to the ability to find information; since most of these can be found with Google, and will be dead in 5 years, they might as easily be omitted.
Joe
_______________________________________________ pilc mailing list pilc@ietf.org https://www1.ietf.org/mailman/listinfo/pilc http://www.ietf.org/html.charters/pilc-charter.html http://pilc.grc.nasa.gov/
This archive was generated by hypermail 2b29 : Tue Jun 11 2002 - 14:18:01 EDT