Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [RPRWG] Review of the Definitions Draft, bs_acpt_02.pdf



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