Re: [NSIS] NSLP versioning

Roland Bless <bless@tm.uka.de> Mon, 12 June 2006 09:56 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpj9t-00078V-Mi; Mon, 12 Jun 2006 05:56:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpj9s-00078Q-M0 for nsis@ietf.org; Mon, 12 Jun 2006 05:56:32 -0400
Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpj9o-00042B-BZ for nsis@ietf.org; Mon, 12 Jun 2006 05:56:32 -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 1Fpj9a-0006qJ-Q7; Mon, 12 Jun 2006 11:56:17 +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 90AAEB4BB; Mon, 12 Jun 2006 11:56:14 +0200 (CEST)
Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1Fpj9a-0006JW-0e; Mon, 12 Jun 2006 11:56:14 +0200
Message-ID: <448D3A3D.6010105@tm.uka.de>
Date: Mon, 12 Jun 2006 11:56:13 +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: john.loughney@nokia.com
Subject: Re: [NSIS] NSLP versioning
References: <BAA65A575825454CBB0103267553FCCC39C930@esebe199.NOE.Nokia.com>
In-Reply-To: <BAA65A575825454CBB0103267553FCCC39C930@esebe199.NOE.Nokia.com>
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: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: stiemerling@netlab.nec.de, nsis@ietf.org, "Hancock, Robert" <robert.hancock@roke.co.uk>
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

Hi John, Martin, Robert, and, all

>> The issue here is whether an NSIS initiator should have the 
>> ability to ask with a single request message for multiple, 
>> different NSLP version.
>> This would require a single general NSLP-ID per NSLP and a 
>> version information with the NSLP itself.
>>
>> I do not know if this issue is solvable by now or if it should 
>> be handled in the NSLP extensibility draft. Since we have only 
>> a single version anyway of each NSLP.
> 
> Is there anyone requesting this feature, it sounds extremely messy to
> actually get working.

I'm actually opposed to supporting such a version negotiation
feature. There are quite a lot of options and cases one could
imagine. I guess it's a good example of applying the
e2e argument again: the application itself should decide
which version is suitable instead of building a version negotiation
feature into GIST. Thus, it would be free to probe
versions in any order it likes given the current NSLP-IP -> version
one-to-one mapping. Furthermore, we have the limited exensibility
for yet unknown objects within each version. I guess that's flexible
enough.

Regards,
 Roland

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