Docs updates.

1 files changed, 197 insertions, 118 deletions

diff --git a/doc/bird.sgml b/doc/bird.sgml
index 9e364f66..5949fea9 100644
--- a/doc/bird.sgml
+++ b/doc/bird.sgml
@@ -176,8 +176,6 @@ protocols.
 
 <sect>Introduction
 
-<!-- fixme: add default values to all places? Where do I learn them? --> 
-
 <p>BIRD is configured using a text configuration file. Upon startup, BIRD reads <file>$prefix/bird.conf</file> (unless the
 <tt/-c/ command line option is given). Configuration may be changed on user's request: if you modify
 config file and then signal BIRD with SIGHUP, it will adjust to the new
@@ -224,15 +222,18 @@ protocol rip {
 	<cf/remote/ for messages about misbehavior of remote machines, 
 	<cf/auth/ about authentication failures,
 	<cf/bug/ for internal BIRD bugs. You may specify more than one <cf/log/ line to establish logging to multiple
-	destinations.
+	destinations. Default: log everything to the system log.
 
-	<!--fixme: mj says explain-->
-				  
 	<tag>debug protocols all|off|{ states, routes, filters, interfaces, events, packets }</tag>
-	Set global default of protocol debugging options.
+	Set global defaults of protocol debugging options. See <cf/debug/ in the following section. Default: off.
+
+	<tag>debug commands <m/number/</tag>
+	Control logging of client connections (0 for no logging, 1 for
+	logging of connects and disconnects, 2 and higher for logging of
+	all client commands). Default: 0.
 
 	<tag>filter <m/name local variables/{ <m/commands/ }</tag> Define a filter. You can learn more about filters
-	in the following chapter.
+	in the following chapter. 
 
 	<tag>function <m/name (parameters) local variables/ { <m/commands/ }</tag> Define a function. You can learn more
 	about functions in the following chapter.
@@ -240,12 +241,12 @@ protocol rip {
 	<tag>protocol rip|ospf|bgp|... <m/[name]/ { <m>protocol options</m> }</tag> Define a protocol
 	instance called <cf><m/name/</cf> (or with a name like "rip5" generated automatically, if you don't specify <cf><m/name/</cf>). You can learn more
 	about configuring protocols in their own chapters. You can run more than one instance of
-	most protocols (like RIP or BGP).
+	most protocols (like RIP or BGP). By default, no instances are configured.
 
 	<tag>define <m/constant/ = (<m/expression/)|<m/number/|<m/IP address/</tag> Define a constant. You can use it later in every place
 	you could use a simple integer or IP address.
 
-	<tag>router id <m/IPv4 address/</tag> Set BIRD's router ID. It's a world-wide unique identification of your router, usually one of router's IPv4 addresses.
+	<tag>router id <m/IPv4 address/</tag> Set BIRD's router ID. It's a world-wide unique identification of your router, usually one of router's IPv4 addresses. Default: in IPv4 version, the lowest IP address of a non-loopback interface. In IPv6 version, this option is mandatory. 
 
 	<tag>table <m/name/</tag> Create a new routing table. The default
 	routing table is created implicitly, other routing tables have
@@ -257,22 +258,39 @@ protocol rip {
 
 <sect>Protocol options
 
-<p>Each routing protocol has its own set of options (see the corresponding sections). These options are common to all protocols:
-
-<descrip>
-	<tag>preference <m/expr/</tag> Sets the preference of routes generated by this protocol.
-
-	<tag>disabled</tag> Disables the protocol. You can change the disable/enable status from the command
-	line interface without needing to touch the configuration. Disabled protocol is not activated.
+<p>For each protocol instance, you can configure a bunch of options.
+Some of them (those described in this section) are generic, some are
+specific to the protocol (see sections talking about the protocols).
 
-	<tag>debug <m/setting/</tag> Similar to global <cf/debug/ setting, except that it only
-	affects one protocol. Only messages in selected debugging categories will be written to the
-	logs.
+<p>Several options use a <cf><m/switch/</cf> argument. It can be either
+<cf/on/, <cf/yes/ or a numeric expression with a non-zero value for the
+option to be enabled or <cf/off/, <cf/no/ or a numeric expression evaluating
+to zero to disable it. An empty <cf><m/switch/</cf> is equivalent to <cf/on/
+("silence means agreement").
 
-	<tag>import { <m/filter commands/ } | <m/name/ | all | none</tag> Specify a filter to be used for filtering routes coming from protocol to the routing table. Default: <cf/all/. <cf/all/ is shorthand for <cf/{ accept; }/ and <cf/none/ is shorthand for <cf/{ reject; }/.
+<descrip>
+	<tag>preference <m/expr/</tag> Sets the preference of routes generated by this protocol. Default: protocol dependent.
+
+	<tag>disabled <m/switch/</tag> Disables the protocol. You can change the disable/enable status from the command
+	line interface without needing to touch the configuration. Disabled protocols are not activated. Default: protocol is enabled.
+
+	<tag>debug all|off|{ states, routes, filters, interfaces, events, packets }</tag>
+	Set protocol debugging options. If asked, each protocol is capable of
+	writing trace messages about its work to the log (with category
+	<cf/trace/). You can either request printing of <cf/all/ trace messages
+	or only of the types selected: <cf/states/ for protocol state changes
+	(protocol going up, down, starting, stopping etc.),
+	<cf/routes/ for routes exchanged with the routing table,
+	<cf/filters/ for details on route filtering,
+	<cf/interfaces/ for interface change events sent to the protocol,
+	<cf/events/ for events internal to the protocol and
+	<cf/packets/ for packets sent and received by the protocol. Default: off.
+
+	<tag>import all | none | filter <m/name/ | filter { <m/filter commands/ } | where <m/filter expression/</tag> 
+	Specify a filter to be used for filtering routes coming from protocol to the routing table. <cf/all/ is shorthand for <cf/where true/ and <cf/none/ is shorthand for <cf/where false/. Default: <cf/all/.
 
 	<tag>export <m/filter/</tag> This is similar to <cf>import</cf> keyword, except that it
-	works in direction from the routing table to the protocol. Default: <cf/none/
+	works in direction from the routing table to the protocol. Default: <cf/none/.
 
 	<tag>table <m/name/</tag> Connect this protocol to a non-default routing table.
 </descrip>
@@ -283,7 +301,7 @@ protocol rip {
 	<tag>passwords { password "<m/password/" from <m/time/ to <m/time/ passive <m/time/ id
 	<m/num/ [...] }</tag> Specifies passwords to be used with this protocol. <cf>Passive <m/time/</cf> is
 	time from which the password is not used for sending, but it is recognized on reception. <cf/id/ is password ID, as needed by
-	certain protocols. Format of <cf><m/time/</cf> is <tt>dd-mm-yy HH:MM:SS</tt>.
+	certain protocols. Format of <cf><m/time/</cf> is <tt>dd-mm-yyyy HH:MM:SS</tt>.
 
 	<tag>interface "<m/mask/"|<m/prefix/ [ { <m/option/ ; [ ... ] } ]</tag> Specifies which
 	interfaces this protocol is active on, and allows you to set options on
@@ -291,14 +309,14 @@ protocol rip {
 	"*" { mode broadcast; };</cf> will start the protocol on all interfaces with <cf>mode
 	broadcast;</cf> option. If first character of mask is <cf/-/, such interfaces are
 	excluded. Masks are parsed left-to-right, thus <cf/interface "-eth*", "*";/ means all but
-	the ethernets.
-						  
+	the ethernets. Default: none.
+
 </descrip>
 
-<sect>Client
+<chapt>Remote control
 
 <p>You can use the command-line client <file>birdc</file> to talk with
-a running BIRD. Communication is done using <file/bird.ctl/ unix domain
+a running BIRD. Communication is done using <file/bird.ctl/ UNIX domain
 socket (unless changed with the <tt/-s/ option given to both the server and
 the client). The client can do simple actions such as enabling/disabling
 protocols, telling BIRD to show various information, telling it to
@@ -309,20 +327,61 @@ codes. You do not necessarily need to use BIRDC to talk to BIRD, your
 own application could do that, too -- format of communication between
 BIRD and BIRDC is stable (see programmer's documentation).
 
-<p>Here is very brief list of supported functions:
+<p>Here is a brief list of supported functions:
 
 <descrip>
-	<tag>dump resources|sockets|interfaces|neighbors|attributs|routes|protocols</tag>
-	Send requested information to a standard logging facility.
+	<tag>dump resources|sockets|interfaces|neighbors|attributes|routes|protocols</tag>
+	Dump contents of internal data structures to the debugging output.
+
+	<tag>show status</tag>
+	Show router status, that is bird version, uptime and time from last reconfiguration.
+
+	<tag>show protocols [all]</tag>
+	Show list of protocols along with tables they are connected to and status, possibly giving verbose information.
 
-	<tag>show status|protocols [all]|interfaces [summary]|symbols</tag>
-	Show requested information on client.
+	<tag>show ospf [interface|neighbors] [<m/name/] ["<m/interface/"]</tag>
+	Show detailed information about OSPF protocol, possibly giving a verbose list of interfaces and neighbors. The <m/name/ of the protocol instance can be omitted if there exists only a single instance.
 
-	<tag>show route [<m/prefix/|for <m/prefix or IP/] [table <m/name/] [table <m/sym/] [all] [stats] [count] [primary] [filter <m/name/] [import_or_proto <m/sym/]</tag>
-	Show contents of the routing table, possibly filtered by the filter. If you put <cf><m/prefix/</cf> on the line, only routes to given destination are shown. You can also make list more verbose by using <cf/all/ or limit routes to be shown to those from given protocol (using <cf/import_or_proto/).
+	<tag>show static [<m/name/]</tag>
+	Show detailed information about static routes. The <m/name/ of the protocol instance can be omitted if there exists only a single instance.
 	
-	<tag>enable|disable|restart <m/name/|all</tag>
-	Enable/disable or restart given protocol.
+	<tag>show interfaces [summary]</tag>
+	Show list of interfaces. For each interface, print its type, state, MTU and addresses assigned. 
+
+	<tag>show symbols</tag>
+	Show list of symbols defined in the configuration (names of protocols, routing tables etc.).
+
+	<tag>show route [<m/prefix/|for <m/prefix or IP/] [primary] [table <m/sym/] [all] [stats|count] [filter <m/name/|where <m/condition/] [(import|proto) <m/sym/]</tag>
+	Show contents of a routing table (by default of the main one),
+	i.e. routes, their metrics and (in case the <cf/all/ switch is given)
+	all their attributes.
+
+	<p>You can specify a <m/prefix/ if you want to print routes for a
+	specific network. If you use <cf>for <m/prefix or IP/</cf>, you'll get
+	the entry which will be used for forwarding of packets to the given
+	destination. By default, all routes for each network are printed with
+	the selected one at the top, unless <cf/primary/ is given in which case
+	only the selected route is shown.
+
+	<p>You can also ask for printing only routes processed and accepted by
+	a given filter (<cf>filter <m/name/</cf> or <cf>filter { <m/filter/ }
+	</cf> or matching a given condition (<cf>where <m/condition/</cf>).
+	The <cf/import/ and <cf/proto/ switches ask for printing of entries as
+	they would be seen by the specified protocol. With <cf/import/, the
+	export filter of the protocol is skipped.
+
+	<p>The <cf/stats/ switch requests showing of route statistics (the
+	number of networks, number of routes before and after filtering). If
+	you use <cf/count/ instead, only the statistics will be printed.
+
+	<tag>enable|disable|restart <m/name/|"<m/pattern/"|all</tag>
+	Enable, disable or restart given protocol instance, instances matching the <cf><m/pattern/</cf> or <cf/all/ instances.
+
+	<tag>configure ["<m/config file/"]</tag>
+	Reload configuration from a given file.
+
+	<tag/down/
+	Shut BIRD down.
 
 	<tag>debug <m/protocol/|<m/pattern/|all all|off|{ states | routes | filters | events | packets }
 	Control protocol debugging.
@@ -435,10 +494,9 @@ incompatible with each other (that is to prevent you from shooting in the foot).
 	  are written as <cf/"This is a string constant"/.
 
 	<tag/ip/ This type can hold a single IP address. Depending on the compile-time configuration of BIRD you are using, it
-	  is either an IPv4 or IPv6 address. IPv4 addresses are written (as you would expect) as
-	  <cf/1.2.3.4/. You can apply special operator <cf>.mask(<M>num</M>)</cf>
+	  is either an IPv4 or IPv6 address. IP addresses are written in the standard notation (<cf/10.20.30.40/ or <cf/fec0:3:4::1/). You can apply special operator <cf>.mask(<M>num</M>)</cf>
 	  on values of type ip. It masks out all but first <cf><M>num</M></cf> bits from ip
-	  address. So <cf/1.2.3.4.mask(8) = 1.0.0.0/ is true. <!-- FIXME: IPv6? -->
+	  address. So <cf/1.2.3.4.mask(8) = 1.0.0.0/ is true.
 
 	<tag/prefix/ This type can hold a network prefix consisting of IP address and prefix length. Prefix literals are written as
 	  <cf><M>ipaddress</M>/<M>pxlen</M></cf>, or
@@ -466,16 +524,15 @@ incompatible with each other (that is to prevent you from shooting in the foot).
 	<tag/bgppath/
 	  BGP path is a list of autonomous system numbers. You can't write literals of this type.
 
-	<tag/bgpmask/ 
-	  BGP mask is a mask used for matching BGP paths
-	  (using <cf>path &tilde; /2 3 5 ?/</cf> syntax). Matching is
-	  done using shell-like patterns: <cf/?/ means
-	  "any number of any autonomous systems". Pattern for single
-	  unknown autonomous system is not supported. (We
-	  did not want to use * because then it becomes too easy to
-	  write <cf>/*</cf> which is start of comment.) For example,
+	<tag/bgpmask/
+	  BGP masks are patterns used for BGP path matching
+	  (using <cf>path &tilde; /2 3 5 ?/</cf> syntax). The masks
+	  resemble wildcard patterns as used by UNIX shells. Autonomous
+	  system numbers match themselves, <cf/?/ matches any (even empty)
+	  sequence of arbitrary AS numbers (<cf/*/ hasn't been chosen, because
+	  <cf>/*</cf> starts a comment). For example:
 	  <tt>/4 3 2 1/ ~ /? 4 3 ?/</tt> is true, but 
-	  <tt>/4 3 2 1/ ~ /? 4 5 ?/</tt> is false. <!-- fixme: formulate better -->
+	  <tt>/4 3 2 1/ ~ /? 4 5 ?/</tt> is false.
 	<tag/clist/ 
 	  Community list is similar to set of pairs,
 	  except that unlike other sets, it can be modified.
@@ -536,7 +593,7 @@ defined using the <cf>defined( <m>attribute</m> )</cf> operator.
 	Network the route is talking about. Read-only. (See the section about routing tables.)
 
 	<tag><m/enum/ scope</tag>
-	Address scope of the network (<cf/SCOPE_HOST/ for addresses local to this host, <cf/SCOPE_LINK/ for those specific for a physical link, <cf/SCOPE_SITE/, <cf/SCOPE_ORGANIZATION/, <cf/SCOPE_UNIVERSE/)
+	Address scope of the network (<cf/SCOPE_HOST/ for addresses local to this host, <cf/SCOPE_LINK/ for those specific for a physical link, <cf/SCOPE_SITE/ and <cf/SCOPE_ORGANIZATION/ for private addresses, <cf/SCOPE_UNIVERSE/ for globally visible addresses).
 
 	<tag><m/int/ preference</tag>
 	Preference of the route. (See section about routing tables.)
@@ -551,10 +608,10 @@ defined using the <cf>defined( <m>attribute</m> )</cf> operator.
 	what protocol has told me about this route. Possible values: <cf/RTS_DUMMY, RTS_STATIC, RTS_INHERIT, RTS_DEVICE, RTS_STATIC_DEVICE, RTS_REDIRECT, RTS_RIP, RTS_OSPF, RTS_OSPF_EXT, RTS_OSPF_IA, RTS_OSPF_BOUNDARY, RTS_BGP, RTS_PIPE/.
 
 	<tag><m/enum/ cast</tag>
-	Route type (<cf/RTC_UNICAST/ for normal routes, <cf/RTC_BROADCAST, RTC_MULTICAST, RTC_ANYCAST/ for broadcast, multicast and anycast routes.) Read-only.
+	Route type (<cf/RTC_UNICAST/ for normal routes, <cf/RTC_BROADCAST, RTC_MULTICAST, RTC_ANYCAST/ for broadcast, multicast and anycast routes). Read-only.
 
 	<tag><m/enum/ dest</tag>
-	Type of destination the packets should be sent to (<cf/RTD_ROUTER/ for forwarding to a neighboring router, <cf/RTD_NETWORK/ for routing to directly-connected network, <cf/RTD_BLACKHOLE/ for packets to be silently discarded, <cf/RTD_UNREACHABLE, RTD_PROHIBIT/ for packets that should be discarded with ICMP host unreachable / ICMP administratively prohibited messages.) Read-only.
+	Type of destination the packets should be sent to (<cf/RTD_ROUTER/ for forwarding to a neighboring router, <cf/RTD_NETWORK/ for routing to a directly-connected network, <cf/RTD_BLACKHOLE/ for packets to be silently discarded, <cf/RTD_UNREACHABLE/, <cf/RTD_PROHIBIT/ for packets that should be returned with ICMP host unreachable / ICMP administratively prohibited messages). Read-only.
 </descrip>
 
 <p>There also exist some protocol-specific attributes, which are described in protocol sections.
@@ -583,22 +640,22 @@ defined using the <cf>defined( <m>attribute</m> )</cf> operator.
 <sect>BGP
 
 <p>The Border Gateway Protocol is the routing protocol used for backbone
-level routing in the today's Internet. Contrary to other protocols, its convergence
+level routing in the today's Internet. Contrary to the other protocols, its convergence
 doesn't rely on all routers following the same rules for route selection,
 making it possible to implement any routing policy at any router in the
 network, the only restriction being that if a router advertises a route,
 it must accept and forward packets according to it.
 
 <p>BGP works in terms of autonomous systems (often abbreviated as AS). Each
-AS is a part of the network with common management and common routing policy.
-Routers within each AS usually communicate using either a interior routing
+AS is a part of the network with common management and common routing policy. It is identified by a unique 16-bit number.
+Routers within each AS usually communicate with each other using either a interior routing
 protocol (such as OSPF or RIP) or an interior variant of BGP (called iBGP).
 Boundary routers at the border of the AS communicate with their peers
 in the neighboring AS'es via exterior BGP (eBGP).
 
 <p>Each BGP router sends to its neighbors updates of the parts of its
-routing table it wishes to export, along with complete path information
-(a list of AS'es the packet will travel through if it uses that particular
+routing table it wishes to export along with complete path information
+(a list of AS'es the packet will travel through if it uses the particular
 route) in order to avoid routing loops.
 
 <p>BIRD supports all requirements of the BGP4 standard as defined in
@@ -608,11 +665,11 @@ latest draft<htmlurl url="ftp://ftp.rfc-editor.org/internet-drafts/draft-ietf-id
 It also supports the community attributes as per
 RFC 1997<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc1997.txt">,
 capability negotiation defined in
-RFC 2842<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc2842.txt">,
+RFC 2842<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc2842.txt">.
 For IPv6, it uses the standard multiprotocol extensions defined in
 RFC 2283<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc2283.txt">
 including changes described in the
-latest draft <htmlurl url="ftp://ftp.rfc-editor.org/internet-drafts/draft-ietf-idr-bgp4-multiprotocol-v2-05.txt">
+latest draft<htmlurl url="ftp://ftp.rfc-editor.org/internet-drafts/draft-ietf-idr-bgp4-multiprotocol-v2-05.txt">
 and applied to IPv6 according to
 RFC 2545<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc2545.txt">.
 
@@ -620,25 +677,25 @@ RFC 2545<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc2545.txt">.
 
 <p>BGP doesn't have any simple metric, so the rules for selection of an optimal
 route among multiple BGP routes with the same preference are a bit more complex
-and are implemented according to the following algorithm. First it uses the first
+and they are implemented according to the following algorithm. It starts the first
 rule, if there are more "best" routes, then it uses the second rule to choose
 among them and so on.
 
 <itemize>
-	<item>Prefer route with the highest local preference attribute.
+	<item>Prefer route with the highest Local Preference attribute.
 	<item>Prefer route with the shortest AS path.
 	<item>Prefer IGP origin over EGP and EGP over incomplete.
 	<item>Prefer the lowest value of the Multiple Exit Discriminator.
-	<item>Prefer internal routes over external routes.
-	<item>Prefer route with the lowest value of router ID of the
+	<item>Prefer internal routes over external ones.
+	<item>Prefer the route with the lowest value of router ID of the
 	advertising router.
 </itemize>
 
 <sect1>Configuration
 
 <p>Each instance of the BGP corresponds to one neighboring router.
-This allows to set routing policy and all other parameters differently
-for each neighbor using the following protocol parameters:
+This allows to set routing policy and all the other parameters differently
+for each neighbor using the following configuration parameters:
 
 <descrip>
 	<tag>local as <m/number/</tag> Define which AS we are part of. (Note that
@@ -646,51 +703,66 @@ for each neighbor using the following protocol parameters:
 	in multiple AS'es simultaneously, but in such cases you need to tweak
 	the BGP paths manually in the filters to get consistent behavior.)
 	This parameter is mandatory.
+
 	<tag>neighbor <m/ip/ as <m/number/</tag> Define neighboring router
 	this instance will be talking to and what AS it's located in. Unless
 	you use the <cf/multihop/ clause, it must be directly connected to one
 	of your router's interfaces. In case the neighbor is in the same AS
 	as we are, we automatically switch to iBGP. This parameter is mandatory.
+
 	<tag>multihop <m/number/ via <m/ip/</tag> Configure multihop BGP to a
 	neighbor which is connected at most <m/number/ hops far and to which
 	we should route via our direct neighbor with address <m/ip/.
 	Default: switched off.
+
 	<tag>next hop self</tag> Avoid calculation of the Next Hop attribute
 	and always advertise our own source address (see below) as a next hop.
 	This needs to be used only
 	occasionally to circumvent misconfigurations of other routers.
 	Default: disabled.
+
 	<tag>source address <m/ip/</tag> Define local address we should use
 	for next hop calculation. Default: the address of the local end
 	of the interface our neighbor is connected to.
+
 	<tag>disable after error <m/switch/</tag> When an error is encountered (either
 	locally or by the other side), disable the instance automatically
-	and wait for an administrator to solve the problem manually. Default: off.
-	<tag>hold time <m/number/</tag> Time in seconds to wait for a keepalive
+	and wait for an administrator to fix the problem manually. Default: off.
+
+	<tag>hold time <m/number/</tag> Time in seconds to wait for a Keepalive
 	message from the other side before considering the connection stale.
 	Default: depends on agreement with the neighboring router, we prefer
 	240 seconds if the other side is willing to accept it.
+
 	<tag>startup hold time <m/number/</tag> Value of the hold timer used
-	before the routers have a chance to exchange OPEN messages and agree
+	before the routers have a chance to exchange open messages and agree
 	on the real value. Default: 240 seconds.
+
 	<tag>keepalive time <m/number/</tag> Delay in seconds between sending
-	of two consecutive keepalive messages. Default: One third of the hold time.
+	of two consecutive Keepalive messages. Default: One third of the hold time.
+
 	<tag>connect retry time <m/number/</tag> Time in seconds to wait before
-	retrying a failed connect attempt. Default: 120 seconds.
+	retrying a failed attempt to connect. Default: 120 seconds.
+
 	<tag>start delay time <m/number/</tag> Delay in seconds between protocol
-	startup and first attempt to connect. Default: 5 seconds.
-	<tag>error wait time <m/number/, <m/number/</tag> Minimum and maximum delay in seconds between protocol
-	failure (either local or reported by the peer) and automatic startup.
+	startup and the first attempt to connect. Default: 5 seconds.
+
+	<tag>error wait time <m/number/,<m/number/</tag> Minimum and maximum delay in seconds between a protocol
+	failure (either local or reported by the peer) and automatic restart.
 	Doesn't apply when <cf/disable after error/ is configured. If consecutive
 	errors happen, the delay is increased exponentially until it reaches the maximum. Default: 60, 300.
+
 	<tag>error forget time <m/number/</tag> Maximum time in seconds between two protocol
 	failures to treat them as a error sequence which makes the <cf/error wait time/
 	increase exponentially. Default: 300 seconds.
+
 	<tag>path metric <m/switch/</tag> Enable comparison of path lengths
 	when deciding which BGP route is the best one. Default: on.
+
 	<tag>default bgp_med <m/number/</tag> Value of the Multiple Exit
 	Discriminator to be used during route selection when the MED attribute
 	is missing. Default: infinite.
+
 	<tag>default bgp_local_pref <m/number/</tag> Value of the Local Preference
 	to be used during route selection when the Local Preference attribute
 	is missing. Default: 0.
@@ -698,47 +770,53 @@ for each neighbor using the following protocol parameters:
 
 <sect1>Attributes
 
-<p>BGP defines several route attributes. Some of them (those marked with `I' in the
+<p>BGP defines several route attributes. Some of them (those marked with `<tt/I/' in the
 table below) are available on internal BGP connections only, some of them (marked
-with `O') are optional.
+with `<tt/O/') are optional.
 
 <descrip>
 	<tag>bgppath <cf/bgp_path/</tag> Sequence of AS numbers describing the AS path
-	the packet will travel through when forwarded according to this route. On
-	internal BGP connections it doesn't contain the number of the local AS.
+	the packet will travel through when forwarded according to the particular route. In case of 
+	internal BGP it doesn't contain the number of the local AS.
+
 	<tag>int <cf/bgp_local_pref/ [I]</tag> Local preference value used for
 	selection among multiple BGP routes (see the selection rules above). It's
 	used as an additional metric which is propagated through the whole local AS.
+
 	<tag>int <cf/bgp_med/ [IO]</tag> The Multiple Exit Discriminator of the route
 	is an optional attribute which is often used within the local AS to
 	reflect interior distances to various boundary routers. See the route selection
 	rules above for exact semantics.
-	<tag>enum <cf/bgp_origin/</tag> Origin of the route: either <cf/ORIGIN_IGP/,
-	if the route has originated in interior routing protocol of an AS or
-	<cf/ORIGIN_EGP/, if it's been imported from the <tt>EGP</tt> protocol
-	(nowadays it seems to be obsolete) or <cf/ORIGIN_INCOMPLETE/, if the origin
+
+	<tag>enum <cf/bgp_origin/</tag> Origin of the route: either <cf/ORIGIN_IGP/
+	if the route has originated in an interior routing protocol or
+	<cf/ORIGIN_EGP/ if it's been imported from the <tt>EGP</tt> protocol
+	(nowadays it seems to be obsolete) or <cf/ORIGIN_INCOMPLETE/ if the origin
 	is unknown.
+
 	<tag>ip <cf/bgp_next_hop/</tag> Next hop to be used for forwarding of packets
 	to this destination. On internal BGP connections, it's an address of the
 	originating router if it's inside the local AS or a boundary router the
 	packet will leave the AS through if it's an exterior route, so each BGP
 	speaker within the AS has a chance to use the shortest interior path
 	possible to this point.
+
 	<tag>void <cf/bgp_atomic_aggr/ [O]</tag> This is an optional attribute
-	which carries no value, but which sole presence indicates that the route
-	has been aggregated from multiple routes by some AS on the path from
+	which carries no value, but the sole presence of which indicates that the route
+	has been aggregated from multiple routes by some router on the path from
 	the originator.
+
 <!-- we don't handle aggregators right since they are of a very obscure type
 	<tag>bgp_aggregator</tag>
 -->
 	<tag>clist <cf/bgp_community/ [O]</tag> List of community values associated
 	with the route. Each such value is a pair (represented as a <cf/pair/ data
-	type inside the filters) of 16-bit integers, the first of them containing a number of the AS which defines
-	the community and the second one is a per-AS identifier. There are lots
+	type inside the filters) of 16-bit integers, the first of them containing the number of the AS which defines
+	the community and the second one being a per-AS identifier. There are lots
 	of uses of the community mechanism, but generally they are used to carry
 	policy information like "don't export to USA peers". As each AS can define
 	its own routing policy, it also has a complete freedom about which community
-	attributes it defines and what their semantics will be.
+	attributes it defines and what will their semantics be.
 </descrip>
 
 <sect1>Example
@@ -746,14 +824,14 @@ with `O') are optional.
 <p><code>
 protocol bgp {
 	local as 65000;				# Use a private AS number
-	neighbor 62.168.0.130 as 5588;		# Our neighbor
-	multihop 20 via 62.168.0.13;		# Which is connected indirectly
+	neighbor 62.168.0.130 as 5588;		# Our neighbor...
+	multihop 20 via 62.168.0.13;		# ... which is connected indirectly
 	export filter {				# We use non-trivial export rules
 		if source = RTS_STATIC then {	# Export only static routes
 		        # Assign our community
 			bgp_community.add((65000,5678));
 			# Artificially increase path length
-			# by prepending local AS number twice
+			# by advertising local AS number twice
 			if bgp_path ~ / 65000 / then	  
 				bgp_path.prepend(65000);  
 			accept;
@@ -761,19 +839,19 @@ protocol bgp {
 		reject;
 	};
 	import all;
-	source address 62.168.0.1;		# Use non-standard source address
+	source address 62.168.0.1;		# Use a non-standard source address
 }
 </code>
 
 <sect>Device
 
-<p>The Device protocol is not a real routing protocol as it doesn't generate
-any routes and only serves as a module for getting information about network
+<p>The Device protocol is not a real routing protocol.  It doesn't generate
+any routes and it only serves as a module for getting information about network
 interfaces from the kernel.
 
 <p>Except for very unusual circumstances, you probably should include
-this protocol in the configuration since almost all other protocol
-require network interfaces to be defined in order to work.
+this protocol in the configuration since almost all other protocols
+require network interfaces to be defined for them to work with.
 
 <p>The only configurable thing is interface scan time:
 
@@ -781,8 +859,8 @@ require network interfaces to be defined in order to work.
 	<tag>scan time <m/number/</tag> Time in seconds between two scans
 	of the network interface list. On systems where we are notified about
 	interface status changes asynchronously (such as newer versions of
-	Linux), we need to scan the list only to avoid confusion by lost
-	notifications, so the default time is set to a large value.
+	Linux), we need to scan the list only in order to avoid confusion by lost
+	notification messages, so the default time is set to a large value.
 </descrip>
 
 <p>As the Device protocol doesn't generate any routes, it cannot have
@@ -802,10 +880,10 @@ by the kernel via the Device protocol.
 
 <p>It's highly recommended to include this protocol in your configuration
 unless you want to use BIRD as a route server or a route reflector, that is
-on a machine which doesn't forward packets and only participates in
+on a machine which doesn't forward packets itself and only participates in
 distribution of routing information.
 
-<p>Only configurable thing about direct is what interfaces it watches:
+<p>The only configurable thing about direct is what interfaces it watches:
 
 <p><descrip>
 	<tag>interface <m/pattern [, ...]/</tag> By default, the Direct
@@ -829,17 +907,17 @@ protocol direct {
 <sect>Kernel
 
 <p>The Kernel protocol is not a real routing protocol. Instead of communicating
-with other routers in the network, it performs synchronization of BIRD's routing
-tables with OS kernel. Basically, it sends all routing table updates to the kernel
+the with other routers in the network, it performs synchronization of BIRD's routing
+tables with the OS kernel. Basically, it sends all routing table updates to the kernel
 and from time to time it scans the kernel tables to see whether some routes have
 disappeared (for example due to unnoticed up/down transition of an interface)
 or whether an `alien' route has been added by someone else (depending on the
-<cf/learn/ switch, such routes are either deleted or we accept them to our
+<cf/learn/ switch, such routes are either deleted or accepted to our
 table).
 
 <p>If your OS supports only a single routing table, you can configure only one
 instance of the Kernel protocol. If it supports multiple tables (in order to
-allow policy routing), you can run as many instances as you want, but each of
+allow policy routing; such an OS is for example Linux 2.2), you can run as many instances as you want, but each of
 them must be connected to a different BIRD routing table and to a different
 kernel table.
 
@@ -848,7 +926,7 @@ kernel table.
 <p><descrip>
 	<tag>persist <m/switch/</tag> Tell BIRD to leave all its routes in the
 	routing tables when it exits (instead of cleaning them up).
-	<tag>scan time <m/number/</tag> Time in seconds between two scans of the
+	<tag>scan time <m/number/</tag> Time in seconds between two consecutive scans of the
 	kernel routing table.
 	<tag>learn <m/switch/</tag> Enable learning of routes added to the kernel
 	routing tables by other routing daemons or by the system administrator.
@@ -859,6 +937,7 @@ kernel table.
 	only on systems supporting multiple routing tables.
 </descrip>
 
+<p>The Kernel protocol doesn't define any route attributes.
 <p>A simple configuration can look this way:
 
 <p><code>
@@ -886,8 +965,6 @@ protocol kernel {		# Secondary routing table
 }
 </code>
 
-<p>The Kernel protocol doesn't define any route attributes.
-
 <sect>OSPF
 
 <sect1>Introduction
@@ -1025,10 +1102,10 @@ protocol ospf &lt;name&gt; {
 	 lacking this password are ignored. This authentication mechanism is
 	 very weak.
 
-	<tag>password <M>text</M></tag>
+	<tag>password "<M>text</M>"</tag>
 	 An 8-byte password used for authentication.
 
-	<tag>neighbors</tag>
+	<tag>neighbors { <m/set/ } </tag>
 	 A set of neighbors to which Hello messages on nonbroadcast networks
 	 are to be sent.
 </descrip>
@@ -1094,21 +1171,21 @@ protocol ospf MyOSPF {
 <sect1>Introduction
 
 <p>The Pipe protocol serves as a link between two routing tables, allowing routes to be
-passed from a table declared as primary (i.e., the one the pipe is connected using the
+passed from a table declared as primary (i.e., the one the pipe is connected to using the
 <cf/table/ configuration keyword) to the secondary one (declared using <cf/peer table/)
 and vice versa, depending on what's allowed by the filters. Export filters control export
 of routes from the primary table to the secondary one, import filters control the opposite
 direction.
 
-<p>The primary use of multiple routing tables and the pipe protocol is for policy routing,
+<p>The primary use of multiple routing tables and the Pipe protocol is for policy routing,
 where handling of a single packet doesn't depend only on its destination address, but also
 on its source address, source interface, protocol type and other similar parameters.
-In many systems (Linux 2.2 being a good example) the kernel allows to enforce routing policies
+In many systems (Linux 2.2 being a good example), the kernel allows to enforce routing policies
 by defining routing rules which choose one of several routing tables to be used for a packet
 according to its parameters. Setting of these rules is outside the scope of BIRD's work
-(you can use the <tt/ip/ command), but you can create several routing tables in BIRD,
+(on Linux, you can use the <tt/ip/ command), but you can create several routing tables in BIRD,
 connect them to the kernel ones, use filters to control which routes appear in which tables
-and also you can employ the Pipe protocol to export a selected subset of one table in
+and also you can employ the Pipe protocol for exporting a selected subset of one table to
 another one.
 
 <sect1>Configuration
@@ -1136,7 +1213,7 @@ and similarly for the second AS. Thus we have split our router to two logical ro
 each one acting on its own routing table, having its own routing protocols on its own
 interfaces. In order to use the other AS's routes for backup purposes, we can pass
 the routes between the tables through a Pipe protocol while decreasing their preferences
-and correcting their BGP paths to reflect AS boundary crossing.
+and correcting their BGP paths to reflect the AS boundary crossing.
 
 <code>
 table as1;				# Define the tables
@@ -1222,12 +1299,12 @@ because there are no good implementations of OSPFv3.
 	  packets are not authenticated at all, <cf/password/ means that a plaintext password is embedded
 	  into each packet, and <cf/md5/ means that packets are authenticated using a md5 cryptographic
 	  hash. If you set authentication to not-none, it is a good idea to add <cf>passwords { }</cf>
-	  section.
+	  section. Default: none.
 
 	<tag>honor always|neighbor|never </tag>specifies when should requests for dumping routing table
 	  be honored. (Always, when sent from a  host on a directly connected
 	  network or never.) Routing table updates are honored only from
-	  neighbors, that is not configurable.
+	  neighbors, that is not configurable. Default: never.
 </descrip>
 
 <p>There are two options that can be specified per-interface. First is <cf>metric</cf>, with
@@ -1271,10 +1348,11 @@ other than equally configured BIRD. I have warned you.
 	<tag>int <cf/rip_metric/</tag> RIP metric of the route (ranging from 0 to <cf/infinity/).
 	When routes from different RIP instances are available and all of them have the same
 	preference, BIRD prefers the route with lowest <cf/rip_metric/.
+	When importing a non-RIP route, the metric defaults to 5.
 
 	<tag>int <cf/rip_tag/</tag> RIP route tag: a 16-bit number which can be used
 	to carry additional information with the route (for example, an originating AS number
-	in case of external routes).
+	in case of external routes). When importing a non-RIP route, the tag defaults to 0.
 </descrip>
 
 <sect1>Example
@@ -1360,12 +1438,13 @@ relevant reading; you can get them from <HTMLURL URL="ftp://ftp.rfc-editor.org/"
 <!--
 LocalWords:  GPL IPv GateD BGPv RIPv OSPFv Linux sgml html dvi sgmltools Pavel
 LocalWords:  linuxdoc dtd descrip config conf syslog stderr auth ospf bgp Mbps
-LocalWords:  router's eval expr num birdc ctl unix if's enums bool int ip GCC
+LocalWords:  router's eval expr num birdc ctl UNIX if's enums bool int ip GCC
 LocalWords:  len ipaddress pxlen netmask enum bgppath bgpmask clist gw md eth
 LocalWords:  RTS printn quitbird iBGP AS'es eBGP RFC multiprotocol IGP Machek
 LocalWords:  EGP misconfigurations keepalive pref aggr aggregator BIRD's RTC
-LocalWords:  OS'es AS's multicast nolisten misconfigured UID blackhole MRTD
+LocalWords:  OS'es AS's multicast nolisten misconfigured UID blackhole MRTD MTU
 LocalWords:  uninstalls ethernets IP binutils ANYCAST anycast dest RTD ICMP rfc
-LocalWords:  compat multicasts nonbroadcast pointopoint
+LocalWords:  compat multicasts nonbroadcast pointopoint loopback sym stats
 LocalWords:  Perl SIGHUP dd mm yy HH MM SS EXT IA UNICAST multihop Discriminator txt
- -->
+LocalWords:  proto wildcard
+-->
\ No newline at end of file