Poll: Indicating tunnel capability

Dear all,

We need to do a decision on how to indicate that a node supports the 
tunnel handling mechanism.

1. The current specification defines a generic NODE_CAPABILITY object 
and introduces one flag to indicate tunnel support, T-bit:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |A|B|r|r|         Type          |r|r|r|r|        Length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |T|                           Reserved                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


2. The other option is to define a 0-length, no flags, object entitled 
NODE_CAPABILITY_TUNNEL. The presence of this object implies support for 
tunnels (no T-bit is needed, the whole 32-bit field is reserved).

So, the question is: do we want to

1. keep this generic node capability object and introduce the first flag 
for this object, the T-bit, or

2. introduce an object only for the tunnel capability?

Option 1 requires some fine-tuning of the text to say the object is 
generic and the tunnel bit T is just the first capability, while option 
2 is a bit simpler to interpret, implement and parse, but is not 
extensible. Option 1 also needs a new IANA registry for the 
capabilities, while option 2 only adds a new object into the existing 
NSLP Object registry.

Please indicate your opinion within two weeks.

Regards,
Jukka