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

[Elwyn Davies <[e-mail]>]

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/




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