Re: [NSIS] NSLP versioning

Roland Bless <bless@tm.uka.de> Fri, 02 June 2006 13:24 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm9dy-0002Of-34; Fri, 02 Jun 2006 09:24:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm9dw-0002Oa-NU for nsis@ietf.org; Fri, 02 Jun 2006 09:24:48 -0400
Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm9dt-0005iN-AQ for nsis@ietf.org; Fri, 02 Jun 2006 09:24:48 -0400
Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1Fm9dm-0007cp-3o; Fri, 02 Jun 2006 15:24:44 +0200
Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id CA27086A3; Fri, 2 Jun 2006 15:24:37 +0200 (CEST)
Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1Fm9dl-0006gp-Fn; Fri, 02 Jun 2006 15:24:37 +0200
Message-ID: <44803C14.3000904@tm.uka.de>
Date: Fri, 02 Jun 2006 15:24:36 +0200
From: Roland Bless <bless@tm.uka.de>
Organization: Institute of Telematics, University of Karlsruhe
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
To: Martin Stiemerling <stiemerling@netlab.nec.de>
Subject: Re: [NSIS] NSLP versioning
References: <3F2E01E1D7B04F4EBEC92D3FA324D8807DCFB1@rsys004a.roke.co.uk> <A07954A1-2A2D-496E-A758-2BFFAFA585CD@netlab.nec.de>
In-Reply-To: <A07954A1-2A2D-496E-A758-2BFFAFA585CD@netlab.nec.de>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: -4.2 (----)
X-Spam-Status: No
X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: nsis <nsis@ietf.org>
X-BeenThere: nsis@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Next Steps in Signaling <nsis.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nsis@ietf.org>
List-Help: <mailto:nsis-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>
Errors-To: nsis-bounces@ietf.org

Martin Stiemerling schrieb:
> Dear all,
> 
> There is still a not completely solved issue back from the old days
> (2004) about NSLP versioning. It is about wether an NSLP can have
> multiple versions or not.

I would say yes, naturally it can. The question is probably
what can be considered as an appropriate demultiplexer.
So what is the issue exactly? Whether there should be an NSLP version
field in the NSLP protocol itself? The current alternative is to
use a different NSLP ID for each version, thus using the NSLP ID
in GIST as demultiplexing value. Since the NSLP ID is 16bit I guess
that there are no issues here. So as long as we assume GIST as
underlying transport (or some other protocol at least carrying session
ID, MRM, NSLPID and so on) there is no problem here. There is
only trouble if all you have is the NSLP data packet alone.

Regards,
 Roland

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis