Revert parts of 1.51 and add a missing \& after "i.e." that is not the

end of a sentence.  Ruslan notes that:

* The part about hexadecimal representation was intentional -- node ID
  is parsed as the ng_parse_hint32_type, and is represented
  (input/output) as a hexadecimal number

* "This value" was more correct, as the alternative name is
  "[<value>]:" where <value> is hexadecimal value of the node ID.

* "ID based name" (which is "[<hexid>]:") was correct, and what's now is
  incorrect -- node ID (number) cannot be equivalent to a name.

1 files changed, 7 insertions, 6 deletions

diff --git a/share/man/man4/netgraph.4 b/share/man/man4/netgraph.4
index 1f54d24..9f457d9 100644
--- a/share/man/man4/netgraph.4
+++ b/share/man/man4/netgraph.4
@@ -110,9 +110,10 @@ characters (including the terminating
 .Dv NUL
 character).
 .Pp
-Each node instance has a unique 32-bit
-.Em ID number .
-This number may be used to refer to a node when there is no
+Each node instance has a unique
+.Em ID number
+which is expressed as a 32-bit hexadecimal value.
+This value may be used to refer to a node when there is no
 .Tn ASCII
 name assigned to it.
 .Ss Hooks
@@ -207,7 +208,7 @@ message should be sent.
 Otherwise, the recipient node's global
 .Tn ASCII
 name
-(or equivalent node ID) is used as the destination address
+(or equivalent ID-based name) is used as the destination address
 for the message (absolute addressing).
 The two types of
 .Tn ASCII
@@ -219,7 +220,7 @@ Only the
 addressing modes are available to control programs outside the kernel;
 use of direct pointers is limited to kernel modules.
 .Pp
-Messages often represent commands which are followed by a reply message
+Messages often represent commands that are followed by a reply message
 in the reverse direction.
 To facilitate this, the recipient of a
 control message is supplied with a
@@ -228,7 +229,7 @@ that is suitable for addressing a reply.
 .Pp
 Each control message contains a 32-bit value, called a
 .Dq typecookie ,
-indicating the type of the message, i.e. how to interpret it.
+indicating the type of the message, i.e.\& how to interpret it.
 Typically each type defines a unique typecookie for the messages
 that it understands.
 However, a node may choose to recognize and