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

From: "Tschofenig, Hannes" <[email-masked]>
Date: Sun, 15 Jan 2006 22:28:33 +0100

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Elwyn Davies <[email-masked]>
Date: Mon, 16 Jan 2006 10:18:41 +0000

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).

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 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.

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?').

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

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/

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 16 Jan 2006 12:15:42 +0100

hi elwyn,

thanks for the quick response.

> section. There are IANA considerations distributed in the document (s6 

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

>` communication is required for the reverse direction (with path-

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

> understanding of this section.

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

> 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

> -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.

> s10: s/Robert already provided us already/Robert also provided us with/
will be fixed.

thanks again.

ciao
hannes