Re: [NSIS] AD review: draft-ietf-nsis-nslp-auth-02.txt

Lars Eggert <lars.eggert@nokia.com> Thu, 17 June 2010 03:36 UTC

Return-Path: <lars.eggert@nokia.com>
X-Original-To: nsis@core3.amsl.com
Delivered-To: nsis@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9B9A3A69FA for <nsis@core3.amsl.com>; Wed, 16 Jun 2010 20:36:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.219
X-Spam-Level:
X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U002vyIAkmCU for <nsis@core3.amsl.com>; Wed, 16 Jun 2010 20:36:08 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id B40C53A69F9 for <nsis@ietf.org>; Wed, 16 Jun 2010 20:36:08 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o5H3a32g022918; Wed, 16 Jun 2010 22:36:10 -0500
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Jun 2010 06:36:05 +0300
Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Jun 2010 06:36:04 +0300
Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o5H3a4GO029531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jun 2010 06:36:04 +0300
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary="Apple-Mail-11--61682658"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Lars Eggert <lars.eggert@nokia.com>
In-Reply-To: <4C12437E.5060701@kit.edu>
Date: Thu, 17 Jun 2010 11:35:44 +0800
Message-Id: <EB5F44F2-0B96-4465-8F02-92EA5408AF86@nokia.com>
References: <20100515224502.402743A6A97@core3.amsl.com> <4C0CA940.7080000@tkk.fi> <99B779C7-3319-465A-8D5D-70FDC8DBA163@nokia.com> <4C12437E.5060701@kit.edu>
To: Roland Bless <roland.bless@kit.edu>
X-Mailer: Apple Mail (2.1081)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Thu, 17 Jun 2010 06:35:58 +0300 (EEST)
X-OriginalArrivalTime: 17 Jun 2010 03:36:04.0915 (UTC) FILETIME=[371B4830:01CB0DCE]
X-Nokia-AV: Clean
Cc: Jukka Manner <jukka.manner@tkk.fi>, "nsis@ietf.org" <nsis@ietf.org>
Subject: Re: [NSIS] AD review: draft-ietf-nsis-nslp-auth-02.txt
X-BeenThere: nsis@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Next Steps in Signaling <nsis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsis>
List-Post: <mailto:nsis@ietf.org>
List-Help: <mailto:nsis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Jun 2010 03:36:09 -0000

Hi,

On 2010-6-11, at 22:09, Roland Bless wrote:
> on 11.06.2010 15:15, Lars Eggert wrote:
>> Summary: Not ready, revision needed, see below.
>> 
>> Meta question: This document is very complex. Do we have any real
> 
> I guess that this problem is caused by the fact that
> the document heavily bases on the
> Session Authorization Policy Element for RSVP (RFC 3520).
> 
>> experience with coupling NSLP authorization with X.500, Kerberos,
>> PGP, etc.? Do any of the experimental implementations use this to
> 
> So the question is: is RFC 3520 really used anywhere in existing
> RSVP deployments? If not, probably we can dismiss most of the
> RFC 3520 legacy stuff and aim for something simpler (that
> is actually my preference), since there is no reason for code
> reuse.

AFAIK RFC3520 is not widely used. But it's too late for major changes like this. If we're unsure about how the authorization function should look like, we can punt on the work item, now that NSIS is only going for Experimental.

>> Section 6.2., paragraph 0:
>>> 6.2.  Processing within the QoS NSLP 
> 
>> Does this mean that this document updates draft-ietf-nsis-qos-nslp?
> 
> Good question. I don't think so, since you perform additional
> actions when implementing  draft-ietf-nsis-nslp-auth, so it
> affects the implementation behavior, but not the basic
> QoS NSLP protocol behavior.

OK. So there is no interoperability issue between nodes that implement nslp-auth and ones that do not.

Lars