[RPRWG] Comments on 802.17b D0.2
Marc, et al,
The following are my comments on Draft 0.2, other than Clause 14. I'll send Clause 14 comments separately.
jl
page vii, Table Of Contents: Please use the standard TOC template. The present list, especially the lack of clause and subclause numbers, is difficult to use.
page xii, Table Of Figures: Please use the standard TOF template.
page 5, 2: There are no change bars for this clause. Is it still here by mistake, or are change bars missing?
page 8, 3.2.25: Definitions should not describe specific process and should not include the term in the definition. Change to a more generic definition, such as "The act of sending a frame to a single station." This is the definition of unicast, so maybe a differentiator such as "The act of sending a frame addressed to a single station, while also carrying additional addressing information" would be better.
page 10, 3.2.51: Why is this marked as changed?
page 11, 3.2.73: This shouldn't refer to services. And definitions are supposed to avoid referencing other definitions. Change to "A frame transmission choice which prevents frame reorder and duplication, except while recovering from failures on the ring, and except that some reordering within conversations may occur during transition between undirected and directed transmission."
page 11, 3.2.76: Port is already defined in IEEE 100. Definitions 12 and 13 both appear to cover how we are using the term. Strike this definition.
page 12, 3.2.82: Definitions should not refer to specifics standards. Definitions should not provide "additional details". Change to "A frame transmission choice which prevents frame reorder and duplication, except while recovering from failures on the ring."
page 12, 3.2.83: Definitions should not be standard-specific. Definitions should not provide "additional details". Change to "A MAC address that is known to belong to a station on the ring." Does this have to be "ring local address"? Could it not be "local address"? If so, change "ring" in the definition to "directly attached network" or "directly attached LAN/MAN/WAN".
page 12, 3.2.84: Definitions should not be standard-specific. Change to "A MAC address that is not known to belong to a station on the locally attached network."
page 13, 3.2.101: Definitions should not refer to specifics standards. Definitions should not provide "additional details". Change to "A frame transmission choice which prevents frame reorder and duplication."
page 13, 3.2.102: Definitions should not be standard-specific. Either move this definition to Clause 5 or change to "A frame requesting a strict frame transmission."
page 13, 3.2.103: This does not appear to have changed. Why does it have a change bar? Remove it if no change from the standard.
page 19, 4: Why do IETF and ISO have change bars? Remove them if no change from the standard.
page 21, 5.1: Correct the Editor's Note, and all other Editor's Notes, to use the standard style.
page 21, 5.1.4: Why do copy and delay have change bars? Remove them if no change from the standard.
page 21, 5.1.10: Why do latency and neighbor have change bars? Remove them if no change from the standard.
page 22, 5.1.17: Why do receive and span have change bars? Remove them if no change from the standard.
page 22, 5.1.20: Why do strip, transit, and upstream have change bars? Remove them if no change from the standard.
page 24, 5.16.1: Change "With permissive mode, unlike relaxed, some reorder" to "With permissive mode, some reorder".
page 28, 6.2.6: I see no need for the enableClientRxExtAddr variable (see 6.4.2.4). Further, I thought we agreed already to remove this. Remove for here and all other occurrences.
page 28, 6.2.7: What if both forceStrict and forcePermissive are true? What if strict_order is provided and is set to true and forcePermissive is true? Clarify what happens in these situations.
page 28, 6.2.7: What do "undirected to directed frame transmissions" and "directed to undirected frame transmissions" mean? Change wording to reflect meaning.
page 31, 6.4.1.2: I see no reasons for the change bars other than the addition of request_sas. Remove them if no change from the standard.
page 33, 6.4.1.2: For strict_order, change "The default value is controlled by the setting of the forceStrict parameter" to "The default value is the setting of the forceStrict variable".
page 33, 6.4.1.2: The MAC does not discard frames; it merely doesn't accept them sometimes. For destination_address_extended and source_address_extended, change "The frame is discarded if this parameter is provided when SAS processing is selected" to "This parameter is not provided when SAS processing is selected".
page 33, 6.4.1.2: For request_sas, change "processing, otherwise" to "processing. Otherwise,".
page 34, 6.4.1.2: Change "Default to the enableSAS setting" to "The default value is the setting of the enableSas variable".
page 34, 6.4.1.4: I see no reason for the change bar. Remove it if no change from the standard.
page 35, 6.4.2.2: I see no reason for the change bar for the end of the parameter list and the following sentence. Remove it if no change from the standard.
page 37, 6.4.3.2: What does it take to kill off OAM_SAS_FLUSH? Remove it from here, and everywhere else in the standard.
page 44, 7.1, Figure 7.2: The arrow leading to the Sas statemachine does not match the other arrows. The box representing the MAC layer is no longer lined up under the bar representing the interface between the MAC client and Mac layer. The PHY_DATA.indication label is no longer completely contained under the interface bar. The PHY layer interface bars are no longer symmetrical with respect to the MAC layer. Correct all.
page 45, 7.2.1: There is no such thing as a SAS receive frame. Change "The queue identifier associated with SAS receive frames" to "The queue identifier associated with SAS receive processing of frames".
page 45, 7.2.1: There is no such thing as a SAS transmit frame. Change "The queue identifier associated with SAS transmit frames" to "The queue identifier associated with SAS transmit processing of frames".
page 45, 7.2.1: SAS_GROUP_ADDRESS is not in the correct alphabetized position.
page 53, 7.2.4: Why do forceStrict and mac_protection have change bars? Remove them if no change from the standard.
page 55, 7.2.5: Why do fromClientMcastClassCFrames and fromClientUcastClassABytes have change bars? Remove them if no change from the standard.
page 62, 7.6.3.5: Change "Figure 7.4" to "Figure 7.5".
page 63, 7.6.3.5: Change "If received frame sourced from SAS enabled station, then associate source station address with client source MAC address and optional VID" to "Associate source station addresses with client source MAC addresses and optional VIDs for frames received from SAS enabled stations".
page 63, 7.6.3.5: Change "Map the address parameters provided in the indication service primitive to satisfy the client receive address conditions" to "Map MAC address fields in received frames to appropriate indication service primitive parameters".
page 70, 7.6.3.13.4: I see no reason for the change bar for the Row 2 and Row 3 row descriptions. Remove it if no change from the standard.
page 71, 7.6.3.13.4: I see no reason for the change bar for the Row 15 and Row 16 row descriptions. Remove it if no change from the standard.
page 72, 7.7: Change "subentities, which are detailed in 7.7.1-7.7.9" to "subentities, which are detailed in 14.4.2 and 7.7.1-7.7.9".
page 75, 7.7.3.4: Place a space before the Row 13 and Row 15 row descriptions. Remove the space before the Row 14 row description. Remove the associated change bar(s) since there should not be any change to these rows from their standard state.
page 78, 7.7.6.4: Replace the spaces before the Row 3 and Row 15 row descriptions. Remove the associated change bars since there should not be any change to these rows from their standard state.
page 84, 9.3.2.6: I see no reason for the change bar. Remove it if no change from the standard.
page 90, 11.4.3.2: Change "A (sas) bit that is set to 1 if the enableSas variable is set to TRUE" to "A (spatially aware sublayer) bit that is set to 1 if the SAS layer is enabled in the station, based on the value of myTopoInfo.sasUser defined in 11.2.5. Add myTopoInfo.sasUser and topoEntry.sasUser to 11.2.5 and 11.2.6, respectively. Mention in the definition of myTopoInfo.sasUser that it is based on the value of sasEnable. Add something corresponding to topoEntry.sasUser in the rprTopoImageStatus MIB attribute.
page 90, 11.4.3: Change "When received, this information is copied to the badFcsUser, conservativeMode, and multichokeUser fields in the topology database (see 11.5)" to "When received, this information is copied to the sasUser, badFcsUser, conservativeMode, and multichokeUser fields in the topoEntry table of the topology database (see 11.5)".
page 93, 11.5.1.1, Table 11.1: Change "SasUser" to "sasUser". Move this row to immediately precede the badFcsUser row.
page 94, 11.5.1.1, Table 11.2: Add a row for sasUser immediately before badFcsUser.
page 124, D.7: Add the MIB changes proposed by Peter at the Piscataway meeting.
page 139, Index: Please use the standard Index template.
page 139, Index: Add all the new information to the index.