Subject: [NSIS] I-D Action:draft-ietf-nsis-nslp-auth-00.txt

From: [email-masked]
Date: Wed, 10 Feb 2010 07:15:02 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Next Steps in Signaling Working Group of the IETF.

	Title           : Authorization for NSIS Signaling Layer Protocols
	Author(s)       : J. Manner, et al.
	Filename        : draft-ietf-nsis-nslp-auth-00.txt
	Pages           : 36
	Date            : 2010-02-09

Signaling layer protocols specified within the NSIS framework may
rely on the GIST (General Internet Signaling Transport) protocol to
handle authorization.  Still, the signaling layer protocol above GIST
itself may require separate authorization to be performed when a node
receives a request for a certain kind of service or resources.  This
draft presents a generic model and object formats for session
authorization within the NSIS Signaling Layer Protocols.  The goal of
session authorization is to allow the exchange of information between
network elements in order to authorize the use of resources for a
service and to coordinate actions between the signaling and transport
planes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-auth-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Jukka Manner <[email-masked]>
Date: Thu, 11 Feb 2010 11:49:54 +0200

Dear all,

As part of the IESG comments, we decided to advance the NSLP-layer 
authorization theme and write down a technical solution.

Please look at the work and provide input on the document. We would like 
to advance this item because practical use of any NSLP actually requires 
authorization. GISt-layer inter-node schemes are not enough.

Regards,
Jukka

On 10.2.2010 17:15, [email-masked] wrote:
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nsis

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 17 Feb 2010 14:35:26 +0100

Dear all

I have read the draft-ietf-nsis-nslp-auth-00.txt and I think that it is in a
good shape!

The only issue I have found with the document is that its intended status is
"Standards Track", I think that is should be "Experimental".

I could not find any other issuess associated with this draft!

Best regards,
Georgios

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jukka Manner
> Sent: donderdag 11 februari 2010 10:50
> To: [email-masked]
> Subject: Re: [NSIS] I-D Action:draft-ietf-nsis-nslp-auth-00.txt
> 
> Dear all,
> 
> As part of the IESG comments, we decided to advance the 
> NSLP-layer authorization theme and write down a technical solution.
> 
> Please look at the work and provide input on the document. We 
> would like to advance this item because practical use of any 
> NSLP actually requires authorization. GISt-layer inter-node 
> schemes are not enough.
> 
> Regards,
> Jukka
> 
> > Signaling layer protocols specified within the NSIS 
> framework may rely 
> > on the GIST (General Internet Signaling Transport) protocol 
> to handle 
> > authorization.  Still, the signaling layer protocol above 
> GIST itself 
> > may require separate authorization to be performed when a node

---

From: Xiaoming Fu <[email-masked]>
Date: Wed, 17 Feb 2010 15:16:26 +0100

Hi

a few comments to this ID:
1. some text is QoS-NSLP specific:
s2: Network elements verify the request
    and then process the resource reservation message based on admission
    policy.
--> reservation, admission are meaningful in QoS context, not 
necessarily for FW/NAT or others.

s3.1: ... to verify the resource reservation request.
--> again, resource reservation

2. AUTH_SESSION, AUTH SESSION
--> AUTH_SESSION (only)

3. Furthermore, session ID, MRI,
    and NSLP ID have to be included into the checksum, too, as specified
    in Section 3.2.6.
--> where is checksum field/calculation defined here?

4. what if a targeted authorizing entity cannot support the requested 
AUTH_ENT_ID sub-types? s.6 does not talk about this. In multi-hop 
signaling cases (not just end host - last hop), this might happen.

Xiaoming

-- 
Xiaoming Fu, http://user.informatik.uni-goettingen.de/~fu