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

[Hannes Tschofenig <[e-mail]>]

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.

   The Accounting-Request
   message is used to transmit the accounting information to the Home
   AAA server, which MUST reply with the Accounting-Answer message to
   confirm reception.

s/Home AAA server/Diameter server

   The Accounting-Answer message includes the
   Result-Code AVP, which MAY indicate that an error was present in the
   accounting message.  A rejected Accounting-Request message MAY cause
   the user's session to be terminated, depending on the value of the
   Accounting-Realtime-Required AVP received earlier for the session in
   question.

I would re-write the last sentence to something like:

"
   The value of the
   Accounting-Realtime-Required AVP received earlier for the session in
   question may indicate that the user's session has to be terminated when
   a rejected Accounting-Request message was received.
"   
   

   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.


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.

   The application
   MUST assume that the AVPs described in this document will be present
   in all Accounting messages, so only their respective service-specific
   AVPs need to be defined in this section.
   
s/this section/that section
 
 
 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.


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

   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.

   

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.



11.  IANA Considerations

   Diameter is not intended as a general purpose protocol, and
   allocations SHOULD NOT be made for purposes unrelated to
   authentication, authorization or accounting.

I would remove this sentence as we already know that Diameter is used
today outside the originally envisioned environment.


 The
   following values are allocated.

         Diameter Common Messages            0
         NASREQ                              1 [RFC4005]
         Mobile-IP                           2 [RFC4004]
         Diameter Base Accounting            3
         Relay                               0xffffffff
        
I would delete the rows for NASREQ and Mobile IP.



14.  References

Please move  [RFC4004], [RFC4005], [RFC4006], [RFC4072], [RFC4740], 
[RFC4306],
 [RFC4291] to the informative reference section.  
 
 
 [RFC3261] -- delete this reference.

You are referencing the updated NAI RFC [RFC4282], instead of
   [4]   Aboba, B. and M. Beadles, "The Network Access Identifier",
         RFC 2486, January 1999.

I guess that this might cause backwards compatibility problems, see 
draft-korhonen-dime-nai-routing-00.txt.   
 
Appendix A.  Acknowledgements

I believe you should make a split between the acks from RFC 3588 and the 
acks for the bis version.
Additionally, I believe that we should thank the folks from the interops 
and also the guys in the design
team for their feedback.
 


I have some comments regarding the security consideration section but I 
am going to cover them in a separate mail.

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