Re: [NSIS] Re: Diameter QoS Draft: Issue #25

Hannes Tschofenig <Hannes.Tschofenig@gmx.net> Mon, 16 January 2006 11:16 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EySLx-0003gu-3K; Mon, 16 Jan 2006 06:16:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EySLv-0003fd-Cc for nsis@megatron.ietf.org; Mon, 16 Jan 2006 06:16:47 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04028 for <nsis@ietf.org>; Mon, 16 Jan 2006 06:15:23 -0500 (EST)
Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EySTo-0004VC-Gd for nsis@ietf.org; Mon, 16 Jan 2006 06:24:58 -0500
Received: (qmail invoked by alias); 16 Jan 2006 11:16:24 -0000
Received: from ip-80-226-200-169.vodafone-net.de (EHLO [10.226.208.137]) [80.226.200.169] by mail.gmx.net (mp039) with SMTP; 16 Jan 2006 12:16:24 +0100
X-Authenticated: #29516787
Message-ID: <43CB805E.1080208@gmx.net>
Date: Mon, 16 Jan 2006 12:15:42 +0100
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Elwyn Davies <elwynd@dial.pipex.com>
Subject: Re: [NSIS] Re: Diameter QoS Draft: Issue #25
References: <ECDC9C7BC7809340842C0E7FCF48C393A8032E@MCHP7IEA.ww002.siemens.net> <43CB7301.8090804@dial.pipex.com>
In-Reply-To: <43CB7301.8090804@dial.pipex.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA04028
Cc: falfano@lucent.com, mccap@lucent.com, Tseno Tsenov <tseno.tsenov@gmail.com>, nsis@ietf.org, "Tschofenig, Hannes" <hannes.tschofenig@siemens.com>
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>
Sender: nsis-bounces@ietf.org
Errors-To: nsis-bounces@ietf.org

hi elwyn,

thanks for the quick response.

Elwyn Davies wrote:
> I just reviewed the updated draft against my previous comments:
> 
> As regards your specific question, I think Issue 25 is adequately covered.
> 
> Most of my other comments are covered. However, there are a couple of 
> points that aren't covered.
> 
> Regards,
> Elwyn
> 
> Remaining Issues:
> 
> The document (still) doesn't have an explicit IANA considerations 
> section. There are IANA considerations distributed in the document (s6 
> and s7.1 at least).

issue added: http://www.tschofenig.priv.at:8080/diameter-qos/issue27


> 
> Unidirectional vs bidirectional flows: I made the comment on the 
> previous version that it should be made clear early on in the doc 
> whether it was dealing with uni- or bi-directional flows. There was a 
> paragraph right at the end of s8 which said:
> If the data communication might be necessary in both directions, from
> Host A to Host B and vice versa, a separate QoS signaling
>` communication is required for the reverse direction (with path-
> coupled signaling). This message exchange is not shown in this
> example.
> This has been removed and there is now nothing about the type of data 
> flows. I think this ought to be remedied.

i think we need to add some text about this aspect. i personally think 
that a discussion about this aspect should go into section 4.4. since 
bi-directional qos reservations are most likely applicable there.

issue added: http://www.tschofenig.priv.at:8080/diameter-qos/issue28

> 
> I made some comments about s5 (regarding whether time based accounting 
> was being mandated or not): Nothong has changed and I can't remember 
> whether this was discussed or not.. I still don't feel I have a good 
> understanding of this section.

this is still an open issue.
http://www.tschofenig.priv.at:8080/diameter-qos/issue15

> 
> I made a couple of comments on s9 (security considerations) which I 
> don't think have been addressed (including 'But what about any specific 
> threats or risks associated with what is going on hereā€¦ should we just 
> say that RFC3588 covers it all?').

the security of the diameter qos application is related to the security 
of the qos architecture itself. hence, the threats and security 
mechanisms are scattered a little bit over the place (e.g., qos nslp, 
gist, ...).

with issue # 4 (see http://www.tschofenig.priv.at:8080/diameter-qos/issue4)
we address one of the aspects that requirements more discussion in the 
document:
1. Bind-Authentication-Session AVP - carries the Diameter session id of 
NASREQ session for network access authentication.


i have created an issue: http://www.tschofenig.priv.at:8080/diameter-qos/issue29

> 
> I haven't changed my view that the refs to -nsis-qos-nslp and 
> -nsis-qspec are normative.

the qspec is normativ but the qos nslp isn't (and it does not have to 
be). we use the content of the qspec for the description of the qos 
parameters but there is no dependency on the qos nslp.


> 
> Editorial:
> s4.2: NAI - Unexpanded acronym.
> s4.2: Not sure if rules require a title for the table :-(
> s4.2: s/generated Acc-Multi-Session-Id AVP Section 7.3/generated 
> Acc-Multi-Session-Id AVP (see Section 7.3)/
> s4.2: s/Result-Code = DIAMETER_LIMITED_SUCCESS, Section 7.1/Result-Code 
> = DIAMETER_LIMITED_SUCCESS - see Section 7.1/
> 
> s4.4: s/to update already authorized flow status/the update of the 
> already authorized flow status/
> s4.4(end): s/.(mostly applicable for local scenarios)/(mostly applicable 
> for local scenarios)./
> 
> s4.5.1: s/Diameter base protocol functionality/Diameter base protocol 
> function/
> 
> s4.5.1 (fig 9): s/TearOn/Delete QoS reservation/ (It got fixed in one 
> place but there are several other instances)
> s4.5.1 (fig 9): where are QoS Reserve and QoS Response messages at the 
> bottom terminated?
> 
> s4.5.2 (fig 10): same comments as for s4.5.1 (fig 9).
> 
> s10: s/Robert already provided us already/Robert also provided us with/
> 
will be fixed.


thanks again.

ciao
hannes

> 
> 
> 
> Tschofenig, Hannes wrote:
> 
>> Hi Elwyn,
>> you provided feedback for the Diameter QoS application draft. We would
>> like to close the open issues based on the draft version -05: 
>> http://tools.ietf.org/wg/aaa/draft-alfano-aaa-qosprot-05.txt
>>
>> Sending final accounting messages after the end of the authorization
>> session
>> http://www.tschofenig.priv.at:8080/diameter-qos/issue25
>>
>> We updated the draft based on your feedback and reflected your comment.
>> We suggest to close the issue based on the draft update.
>> Ciao
>> Hannes
>>  
>>
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 
> 


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