Re: Poll: Indicating tunnel capability

Hi Jukka

Since option 1 is more extensible than option 2 I would select option 1
to be specified in "draft-ietf-nsis-tunnel-xx"

Best regards,
Georgios


On 3/26/2010, "Jukka Manner" <[email protected]> wrote:

>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
>_______________________________________________
>nsis mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/nsis