Clause 10.7.6.1 states "MRPDU transmission as a result of the operation of a state machine in a Bridge occurs only through the Port associated with that state machine, and only if that Port is in the Forwarding state." This requirement (regardless of interpretation) is in conflict with 10.3.(e), which states "If a port is removed from the set [of Ports in the Forwarding state for a given MAP Context], and that Port has declared one or more attributes, then this Port transmits a Leave message (see 10.6) for every attribute that it has declared." 10.3.(e) specifically requires that a port, which is no longer in the Forwarding state, transmits a Leave message. Further, beyond the conflict with 10.3, interpretation of 10.7.6.1 is unclear with respect to spanning tree contexts. In an SST environment, the behavior identified here is interpretted clearly: Ports which are not in the Forwarding state do not transmit MRPDUs. However, correct behavior is not clear in an MST environment. In an MST environment, a port may be in the set of Forwarding ports in some spanning tree instances, but not in the Forwarding set in other spanning tree instances, and because this sub-clause is governing transmission of MRPDUs as a whole, rather than individual attributes, no specific spanning tree context is readily identifiable. One might take a step beyond what is actually indicated in this subclause, and interpret it to mean that MRPDUs transmitted on a port do not include events for Attributes associated with spanning tree instances for which this port is not in the Forwarding state. This, however, leaves 4 problems: -What if an AttributeEvent is only being encoded for the sake of efficiency? -LeaveAll events are not defined to be associated with any Spanning Tree context. -Domain attributes are not defined to be associated with any Spanning Tree context. Further here, it is undesirable to ever block Domain declarations unless the port is not Forwarding in ANY Spanning Tree Instance. (Because streams for the associated SR Class may be transmitted on any VLAN.) -This still leaves a conflict with 10.3.(e), which indicates that Leave events are transmitted when an attribute becomes blocking. The intent of the prohibition from transmitting MRPDUs on blocked ports is unclear. The only (marginally) desirable effect it seems to produce is that of slightly reducing the bandwidth used on the link (which, in the point-to-point case is effectively blocked anyways). It may have been intended to avoid propagating declarations along pathways through the network which are at least partially blocking (which also would prevent information loops), however, this is already accomplished by the MAP function for each MRP application, which (for all currently defined applications) does not propagate declarations to or from blocking ports. Therefore, the proposed solution is simply to omit the requirement that blocking ports do not transmit MRPDUs. This solution avoids the conflict with 10.3.(e), avoids confusion over which Spanning Tree instance is considered in the case of LeaveAll events or Domain messages, and also avoids the undesirable consequences associated with blocking Domain messages (which do not propagate).