Ad-hoc NSI f2f meeting at Joint Tech 2012 Winter: Present: Chin Guok Hans Trompert Jeroen van der Ham Jerry Sobieski John MacAuley Tom Lehman Tomohiro Kudoh Xi Yang There was consensus on the following: 1. An STP can have 0 or more <type,value> tuples  => STP (<network_id>, <local_id>, <type_1,value_1>, .. , <type_n,value_n>)      - e.g. STP (NetA, EndPt1, port, 1000, vlan, 123)      - open question on how tuples can relate to one another, e.g. port  1-4 have vlans 1-4 The STP specification incorporating the <type,value> tuples is still just a STP *identifier*.   I.e. this in itself does not imply that these values are in any way related to specific technology or hardware features. On the other hand, <type,value> tuples can be used to define capabilities. The capabilities can describe technology, hardware, policy, or other limitations. The value of the "type" string is not defined as part of the NSI CS standard, i.e. it is defined as part of the service definition.  The NSI CS standard only codifies the presence of <type,value> pairs as part of the STP identifiers. It is up to the provider (PA) to define them. However, we do expect that there will be a best-practices document describing some <type,value> combinations and capabilities. 2. The <value> filled can be an individual value or a range      - if a <value> is a range then it is a "STP_Bundle"    I.e., these tuples may also be used to specify constraints that identify a set of STPs. 3. Open question on how we can describe constrains for STPs, e.g.      STP (NetA, EndPt1, <port, $1>, <vlan, $2>)      STP (NetA, EndPt1, <port, $3>, <vlan, $4>)      Capabilities: $1 != $3, $2 = $4  => no vlan translation 4. Open question on how we can describe and bundle SDP