|
Bob,
Thanks for your detailed comments on version 2 of the T&D doc.
I will incorporate these, and comments from others, in a third version
of the document that will be available by Monday, July 2 on the 'July Presentations'
web page, so working group participants can have a week to look at the
material before the discussion and vote. Version 2 (on the web page)
was intended for T&D Ad Hoc discussion, but with the meeting approaching,
it would be reasonable for people to discuss the more controversial issues
on the main reflector.
On the question of alphabetical listing, there is a complete alphabetical
listing at the end of the document, with the page numbers where terms can
be found. It would be possible to reverse this. That is, we
could have the main list be alphabetical and the appendix grouped by topic.
Comments welcomed on this.
In version 3, all definitions (and alternate definitions) will be written
out. I'm working on that now.
Regards, Bob
RDLove wrote:
All,
Bob Sultan and his Ad-Hoc group did an outstanding job compiling and posting
definitions for us to use in the creation of our 802.17 RPR standard.
The draft bs_acpt_02.pdf is available for downloading and review.
On Monday afternoon we will vote on accepting the entire set of terms,
or some subset of them. It is important that we spend the time to
carefully review the terms and conduct email discussion on controversial
areas before the Portland meeting. Hoping
that this is the first of many emails suggesting improvements to the document,
I hereby submit my first set of proposed changes: Global
comment: I would like to see all terms listed strictly alphabetically,
so that we think of each definition in a more universal context, rather
than just as it might be used in a subset of the standard. I will
also need to see all definitions written out that I am to vote on.
The ones that just have references are not yet ready for review. Specific
comments: change:spatial
reuse protocol (SRP): An RPR protocol proposed by Cisco Systems,
described in IETF RFC 2892, August 2000.
to:spatial reuse protocol (SRP):
An RPR protocol , described in IETF RFC 2892, August 2000.
I believe that reference to a single company is inappropriate within a
standard if it can be easily avoided. I
advocate leaving "medium agnostic" and payload agnostic in place until
we see that the terms are not used within the draft that goes out for ballot.
That would be the right time to remove them. Because we use the terms
in our objectives, it is a good idea to have crisp definitions while we
are creating the drafts. change:
station (data station): [adapted
10 from IEEE 100 (C/EMB/LM) 1073.3.1-1994, 1073.4.1-1994,
8802-5-1995] A device that may be attached
to a shared medium network for the purpose of
transmitting and receiving information
on that shared medium. A data station is identified by a
destination address.
to:
station (data station): [adapted
10 from IEEE 100 (C/EMB/LM) 1073.3.1-1994, 1073.4.1-1994,
8802-5-1995] A device that may be attached
to a network for the purpose of
transmitting and receiving information
on that shared medium. A data station is identified by its
MAC address.
because, station is a commonly
used term in both shared media and dedicated media networks. In addition,
the station has a single address, whether it is used for sourcing or receiving
data.The definitions of
"upstream station" and "downstream station" should be changed to eliminate
the words "upstream" and "downstream" within those definitions. The
definition is easier to make after defining a link. For any link,
the Upstream station is the data source, the Downstream station is the
data sink.Also for the definitions
of "upstream" and "downstream" on page 4: Those terms have to do
with relative positioning, and not with direction as stated in those definitions.
Change those definitions to reflect their correct meaning. For example: Upstream:
The position of the source station on a ringlet.Downstream:
The position of the sink station on a ringlet.On
page 3, data sink needs to be on a new line. Also, I recommend dropping
the first definition of "data sink" which is the same as the first definition
of data source, "The functional unit
that provides data for transmission." That definition adds nothing
but confusion.I believe
the first definition of "Port" should suffice for 802.17. In
the first definition of "ringlet" change "circular" to "closed path".
Likewise, search for the word "circular". In general, "closed path"
would be the preferable term. For example, in the definition of "ring
medium".For "dual-ring" and "multi-ring" I believe
we must add the concept that each ringlet connects the same set of stations
in the same or exactly reverse order. Again, use of the word "concentric",
like use of the word "circular" should be eliminated. In addition,
for "dual-ring" add "whose transmission paths are in opposite directions"
or words to that effect.For biconnected
and multiconnected rings, it may be more clear to say they intersect at
"two" and "more than two" "stations" rather than "points". Frame
is defined in terms of PDU (Protocol Data Unit), but this is an undefined
term. Please add it (See Page 882 of the IEEE 100 dictionary, definition
#1). The second definition
of strip: "[ISO 8802.25 25.04.09] An
action taken by an originating data station to remove its frames from the
network after a successful transit of the data around the ring." should
be deleted. The first is better and is sufficient.
For: receive
(receipt, reception) : The reception of a frame on a
link by a station. Change "reception" to "copying" to avoid
circularity.
change: bit rate:
[ISO/IEC2382-09 9.03.01] The speed at which bits are transferred.
to:
bit rate: [ISO/IEC2382-09
9.03.01] The number of bits per second that are transferred.
Note
that the speed at which bits are transferred can be measured as a fractional
amount of "c" the speed of light.
For "plug and play" I like
definition #1.
The definition of "ring segment" under
the "discovery" terms is too specific to the discovery process. A
ring segment can be a segment of a complete ring that is being examined
for any of a variety of reasons, such as "the traffic flow on this ring
segment is heavier than the flow on that ring segment."
For the definition of "ring latency"
change "includes" to "is equal to the sum of"
I propose we delete "round trip propagation
time" If we need to, we can add "ring transmission path latency"
as the ring latency minus the latency of the stations on the ring.
The definitions of "significant instant"
and "significant interval" shed no light on their meanings to me.
Can someone do better?
MTU transparency is defined without
defining MTU. Please define MTU. Note, I would add "in a single
packet" to the end of the IEEE 100 definition (p675): "The largest amount
of data that can be transferred across a given physical network." Best
regards, Robert D.
Love
Chair, Resilient Packet Ring Alliance
President, LAN Connect Consultants
7105 Leveret Circle
Raleigh, NC 27615
Phone: 919 848-6773
Mobile: 919 810-7816
email: rdlove@xxxxxxxx
Fax: 208 978-1187
|