IP over SMDS Internet Draft

[Philippe Prindeville <[e-mail]>]

Here are some comments on reading the Internet Draft.  Sorry
it took so long.  Between vacation and changing jobs, I'm
quite behind in my mail!

Page 1:

RFCs always have jagged margins, and no center title.  Format is:

Network Working Group					<Author's Name(s)>
Internet Draft: XXX					<Author's Address(es)>
							<Date>


				<Title>
  ...

<Author's Name(s)>					[Page 1]


<Internet Draft XXX>		<Short Title>		<Date>

(same footer as before)


"Acknowledgement" should read "and text from [4]", not "and text from
RFC 1042[4]", as this is a redudant reference.  Same for "[5]".

Must, Shall, Mandatory, etc. don't need to be quoted if in capitals.

Page 3:

There are no footnotes in RFCs.

Page 4:

"For each LIS a single SMDS groups address" => "... group address"

"and will different" => "and will be different"

"address of the the IP station" => "... of the IP station"

Also, one needs to be able to discover the hardware address (not
quite an appropriate name -- does a telephone have a hardware
address?  not really).  Perhaps a loopback mechanism whereby the
switch fills in the source or destination address?

"Group Address(smds$lis_ga)" => "Group Address (smds$lis-ga)".  Don't
mix "-" (hyphen) with "_" (underscore) -- it's confusing.

Page 5:

You should show the length of each field (such as PID) in
octets, by using "+"s to mark octet boundaries.  Ie.

	+--+--+--+------+----+
	|  PID   | Ethertype |
	+--+--+--+------+----+

denotes that PID is 3 octets long, whereas Ethertype is 2 octets long.

Also, one never says "byte" in an RFC -- always "octet" (see Byte Order).

What is "Internet decimal"?  Do Internet people use an alternate base 10?
Or do you mean big endian (in which case, just say "big endian")?

Page 6:

Don't write "Id." -- the "." is redundant.  Write Id or Identifier.

For references, ie. "[8]", there is always a space before the "[".

The text says (page 5):

+ The control value in the LLC header is 3 (Unnumbered Information).

and goes on to say (page 6):

"IEEE 802.2 LLC Type 1 Unnumbered Information (UI) communication..."

I just was told that UI is 3...  what is going on?

"for IP packets is shown in Figure 3.  The data link encapsulation
for ARP packets is shown in Figure 4." =>

"for IP packets is shown in Figure 3, and for ARP in Figure 4."

Ethertype for ARP is 0806, not 0800 in Figure 4.

Page 7:

+ The hardware type code assigned for SMDS is <tbd>2.

No footnotes.  "assigned to", not "for".  Also, use Type 6 because a
60-bit universal numbering plan is a 60-bit UNIVERSAL numbering plan.
Let's not invent new types.  If the address will be the same in both
number spaces, then it is the same address type.

"4 bit address type" => "4 bit Address Type"

Does one really need to understand the 4+60 bit structuring?  Since
we always will use both together, why not consider it an opaque
tuple of 64 bits?  802.3 addresses are 2+46 bits, after all...

"instead of to the group address" => "instead of the group address"

Also, Footnote 4 can be included inline.

Page 8:

"IP Multicast Support"

Since SMDS will be used mostly for connecting LANs (via routers)
and not hosts directly, most SMDS-LIS will be router-to-router
broadcasting (see [13]), which does not present a problem...

"8-bit bytes" => "octets".

Page 9:

No mention is made of the Path MTU Discovery protocol.  This is
more appropriate than TCP Maximum Segment Size (MSS) options, since
one of the appeals of SMDS is for distributed computing applications,
like RPC architectures (ie. using UDP and VMTP, which might have
large, single packet transactions) and need MTU discovery.

"Both RFC 1042[4] and RFC 1103[5]" => "Both [4] and [5]"

Need a reference to "IEEE Std. 802.2"

Page 10:

One should list:

	Author's address (both postal and e-mail, maybe phone # also)

	IP over SMDS Working Group members.

Reference 5 needs an RFC number, address, date.