+---------------------------------------------------------------------+
| IEEE 802.1 REVISION REQUEST XXXX                                    |
+------------------===================================----------------+

DATE: July 3, 2012
NAME: Aaron Stewart, Bob Noseworthy
COMPANY/AFFILIATION: University of New Hamsphire's InterOperability Lab with support from the AVnu Alliance
E-MAIL: astewart@iol.unh.edu; ren@iol.unh.edu


REQUESTED REVISION:
     STANDARD: 802.1Q-2011
     CLAUSE NUMBER: 5.4.4, 10.3, 35.2.4
     CLAUSE TITLE: MSRP requirements, 


RATIONALE FOR REVISION:

Clause 5.4.4 requires MSRP to make use of the MAP operation specified in 
10.3.1; however, clause 10.3 clearly states:
"The MAP function for the MSRP application is specified in 35.2.4."
Further, 35.2.4 indicates:
"For the Talker and Listener attributes MSRP propagates attributes in a 
manner different from that described in 10.3 for MMRP and MVRP"

5.4.4, 10.3, and 35.2.4 must be made consistent.  

Currently, there is no MAP behavior defined for how new or non-new attributes 
are propagated or what to do when tcDetected occurs. 

per 10.1 last paragraph: The rules applied to the marking and propagation of 
newly declared values in this way are common to all MRP Applications; however,
the action taken on receipt of an attribute declaration marked as new is 
specific to each MRP Application


PROPOSED REVISION TEXT:

Remove the conflict between 5.4.4 and 10.3/35.2.4.
TWO substantial changes:

#1:
5.4.4(d) to point to 35.2.4.5 rather than 10.3.1.
5.4.4(d) also must not reference the "Base Spanning Tree Context" but rather
should reference the "single context" referred to in 35.2.4.5

Re-write 5.4.4(d) as follows:
"Propagate registration information in accordance to the the single context for 
MSRP attribute propagation that includes all Bridge Ports, as specified in 
35.2.4.5."


#2:
Add to 35.2.4 or anyplace deemed more fitting: 

For any MAD_Join.indication, or any MAD_Join.request being propagated by the 
MSRP Atribute Propagation, 
if the 'new' parameter in the request being propagated is TRUE, then the 
value of the 'new' parameter in the propagated MAD_Join.request is set TRUE.  
If the value of tcDetected (13.23) for the Port providing the 
MAD_Join.indication and MAP Context is nonzero, then the value of the 'new' 
parameter in the propagated MAD_Join.request is set TRUE, regardless of the 
value of this parameter in the indication or request that is being propagated.
Otherwise the 'new' parameter in the propagated request is FALSE. 


IMPACT ON EXISTING NETWORKS:

Without standard specified behavior, existing implementations may vary in 
their MAP operation, specifically in regard to 'new'

+---------------------------------------------------------------------+
| Please attach supporting material, if any                           |
| Submit to:- Tony Jeffree, Chair IEEE 802.1                          |
|  and copy:- Paul Congdon, Vice-Chair IEEE 802.1                     |
|    E-Mail: stds-802-1-maint-req@ieee.org                            |
|                                                                     |
|            +------- For official 802.1 use -----------+             |
|            | REV REQ NUMBER:                          |             |
|            | DATE RECEIVED:                           |             |
|            | EDITORIAL/TECHNICAL                      |             |
|            | ACCEPTED/DENIED                          |             |
|            | BALLOT REQ'D YES/NO                      |             |
|            | Status: X                                |             |
|            +------------------------------------------+             |
+---------------------------------------------------------------------+