Re: [Dime] draft-ietf-dime-rfc3588bis review (2/3)

[Victor Fajardo <[e-mail]>]

Hi Hannes

As with the 1st part of the review, editorial are ok. Other comments 
inline. Changes are incorporated in draft-*13.txt:


> Here is the 2nd part of my review:
>
> 9.2.  Protocol Messages
>
>    A Diameter node that receives a successful authentication and/or
>    authorization messages from the Home AAA server MUST collect
>    accounting information for the session.
>
> s/Home AAA server/Diameter server
>
> I wonder why there is this MUST statement here. Why is there MUST 
> regarding the
> collection of accounting information.
>   

I'm guessing this is historical remnants that is no longer valid in the 
way we use Diameter today. We should relax this to a SHOULD.

>    
>
>    Each Diameter Accounting protocol message MAY be compressed, in order
>    to reduce network bandwidth usage.  If TLS is used to secure the
>    Diameter session, then TLS compression [RFC4346] MAY be used.
>    
> I wonder why this compression aspect is mentioned as there is nothing in 
> Diameter itself
> to provide this compression. Compression is provided by TLS for all 
> Diameter
> messages.
>   

Ok. I suggest we remove it as it does not add value in anyway.

>
> 9.3.  Accounting Application Extension and Requirements
>
>    Each Diameter application (e.g., NASREQ, MobileIP), MUST define their
>    Service-Specific AVPs that MUST be present in the Accounting-Request
>    message in a section entitled "Accounting AVPs".
>
> I wonder why this is a MUST requirement.
>   

Probably the same reason as above. Lets relax to a SHOULD.

>  
>  
>  9.6.  Correlation of Accounting Records
>
>    The Diameter protocol's Session-Id AVP, which is globally unique (see
>    Section 8.8), is used during the authorization phase to identify a
>    particular session.
>
>
>    Services that do not require any authorization
>    still use the Session-Id AVP to identify sessions.
>
>
> Why is the authorization exchange mentioned here explicitly. Session-IDs 
> are used
> throught Diameter and there is nothing specifial about the authorization 
> phase.
>   

Same as above. It seems like 9.6 is binding accounting specifically to 
authz only. We should re-phrase the 1st paragraph to:

        "If an application uses accounting messages, it can correlate 
accounting
         records with a specific application session by using the 
Session-Id of the
         particular application session in the accounting messages. 
Accounting
         messages MAY also use a different Session-Id from that of the 
application
         sessions in which case other session related information is 
needed to
         perform correlation."

>
>    
>    Accounting
>    messages MAY use a different Session-Id from that sent in
>    authorization messages.  Specific applications MAY require different
>    a Session-ID for accounting messages.
>    
> These two sentences essentially say the same thing. Maybe it would be 
> useful to say
>  when the session ID is different.
>   

See above.
>  
>  
>    However, there are certain applications that require multiple
>    accounting sub-sessions.  Such applications would send messages with
>    a constant Session-Id AVP, but a different Accounting-Sub-Session-Id
>    AVP.  In these cases, correlation is performed using the Session-Id.
>    
> The last sentence essentially says what the sentence said previously.
>
>    It is important to note that receiving a STOP_RECORD with no
>    Accounting-Sub-Session-Id AVP when sub-sessions were originally used
>    in the START_RECORD messages implies that all sub-sessions are
>    terminated.
>   

Let's re-phrase this entire paragraph with:

        "In cases where an application requires multiple accounting 
sub-session,
         an Accounting-Sub-Session-Id AVP is used to differentiate each 
sub-session.
         The Session-Id would remain constant for all sub-sessions and 
is be used
         to correlate all sub-sessions to a particular application 
session.</t>
         Note that receiving a STOP_RECORD with no 
Accounting-Sub-Session-Id AVP
         when sub-sessions were originally used in the START_RECORD messages
         implies that all sub-sessions are terminated."

>    Furthermore, there are certain applications where a user receives
>    service from different access devices (e.g., Mobile IPv4), each with
>    their own unique Session-Id.
>
> I am not sure is meant with the Mobile IPv4 example here.
> Is this referring to the case that a user might, as part of their 
> service usage,
> trigger multiple Diameter exchanges from different Diameter clients, 
> such as from
> the NAS and also from an application server?
>
>    In such cases, the Acct-Multi-Session-
>    Id AVP is used for correlation.
>
> I would move this sentence after the subsequent paragraph.
>  
>    During authorization, a server that
>    determines that a request is for an existing session SHOULD include
>    the Acct-Multi-Session-Id AVP, which the access device MUST include
>    in all subsequent accounting messages.
>   

How about re-phrasing the whole paragraph to:

        "There are also cases where an application needs to correlate 
multiple
         application sessions into a single accounting record; the 
accounting record
         may span multiple different Diameter applications and sessions 
used by
         the same user at a given time. In such cases, the 
Acct-Multi-Session-
         Id AVP is used. The Acct-Multi-Session-Id AVP SHOULD be 
signalled by the
         server to the access device (typically during authorization) 
when it
         determines that a request belongs to an existing session. The 
access device
         MUST then include the Acct-Multi-Session-Id AVP in all subsequent
         accounting messages."
>    
>
> 10.1.  Base Protocol Command AVP Table
>
>
> There are a couple of AVPs in the table that do not appear in any command.
> I wonder whether it makes sense to actually list them in the table at all.
> Instead, one could argue that they are rather defined in this document 
> since
> they are of general usage for applications.
>
>   

I'm not sure how we can represent these dangling AVPs. Maybe a separate 
list for them ?


regards,
victor

_______________________________________________
DiME mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dime